D5 Render Test
Janita Locklin
My question is if I should be using a beforeAll in each test pre-rendering the component within that block, so each test doesn't have to re-render the component from scratch since my test suites always start from the same base component. Is there a performance improvement by doing this?
It is mostly a matter of personal preference, but also about how your component works. You may need to render your component in different contexts (props, mocked redux store, mocked provider...). Render component in beforeEach may be faster but makes it more difficult to change the test conditions.
In my experience, as a rule of thumb, presentational components are rendered in the test itself, because I want to test different sets of props to cover all cases. As they are dumb components (only props involved, few mocks, simple component logic), thoses tests are usually fast. This is "real unit testing" : testing a pure function I/O (I only write functional components in my current position).
For smart/bigger components, usually I test a group of components together (which is more an integration test), I have to setup mocks (redux, http services...), and tests tends to resemble to scenarios like you would see in Cypress, with user interactions. For those tests I render once in beforeEach, and write fewer but longer tests. I end up with a test execution time much longer, but with a high level of confidence (close to what E2E would give).
While It makes sense (to me) theoretically, at least with recent version of Jest and RTL, by default it won't work to render in beforeAll. You can get around Jest auto cleanup in afterEach, but the performance benefit is probably not much anyway.
I just started studying "Mastering React Test-Driven Development" by Daniel Irvine, and I figured that it shouldn't be too hard to convert the examples to React 18. But I am running into trouble converting the very first test in the book using Jest.
After some more digging around, I've found that act() can be used in React 18 to force renders to occur before test asserts are checked. This allows for the tests to run immediately without waiting for Jest's done() to timeout when a test fails.
i have this habit of creating quick scenes to procrastinate before getting some actual work done. not that this is a very effective time to spend, rendering vases is imho rather a waist (then better do a real if you have the means), anyway inspired by this recent vase i wanted to give cycles yet another try. no environment, 3 lights.
i tried subsurface scattering (maybe too little) and clear coat. @nathanletwory is clearcoat generally the parameter for reflection? or is the reflection only handled by the roughness i am still not entirely sure.
Clearcoat is for simulation some sort of finish layer on top of the material. That is why there is a clearcoat bump/normal and a clearcoat roughness channel to control the appearance of that coating layer. And as the name says: the coating is only clear.
so this is basically responsible for the reflection per se? i am a bit unsure about it because in a different renderer there are 2 different settings, one for the strength of the reflection and one for the roughness of the reflection, meaning that reflection can be increased while roughness makes the reflection scatter.
As said, roughness mainly does glossy reflection, but then there is also the metallic reflection input. If you need something to funtion like a mirror you set metallic to 1.0 with white base color. The roughness then controls the scattering of the reflection.
Below a setup with metallic 100, roughnesses of 0, 50 and 100. The front row has clearcoat 100, and the backrow has clearcoat 0. Note that the front row appears to have a clean, shiny coat on top of its metallic surface. The backrow is missing that. Most clear to see in the two spheres on the right. Front sphere has environment relfection in its coat layer, the back sphere has not.
Clearcoat is like a layer of lacquer on top of the actual surface material. That lacquer can be highly polished (clearcoat roughness 0) or not. Or you can have it be slightly deformed with a normal or bump map - which is separate from the normal/bump map of the rest of the PBR.
the results of metallic 100 roughness and clearcoat in the lower image look very similar to the 0 roughness 0 metallic and no clearcoat setting in the first image, just that the color is darker, but that confuses me at least.
you get additional environmental reflection with clearcoat? and would the light refract stronger/different according to the bumps/structure of the clearcoat, at least if a normal or displacement map would be used?
here i built up a scene from scratch, just one emission above. the reflections do not get stronger actually no matter how strong the light is or do i really just have to sit it out? here the light actually burns out the light reflection. in the image below i subtled it down a bit.
after furether testing it somehow does effect the reflection when i have more light coming from different angles, so i assume this is a bit of a limitation of raytraced in general, which on the other side makes it more physical i believe.
oh @nathanletwory one a bug which i have noticed which drives me a bit nuts, when i change the lights, either emission strength or light strength or similar when raytraced is active it often if not always happens that it deactivates the lights and switches to default light, then i found the only way out is to switch to rendered mode for short and reinitiate raytraced viewport.
I should apologize for using mixed values. Old Rhino used often values from 0 to 100 as a percentage really. It is still visible in the texture amount fields. The PBR fields are generally 0.0 to 1.0. Old style 100 equals new style 1.0.
To understand best how roughness from the Base Color / Metallic / Roughness section (add through the Detailed settings dropdown) works have just the pbr material with white color and see the differences of roughness values 0.0, 0.5 and 1.0 (which would be in old-school speak 0, 50 and 100).
Roughness means how much light is scattered from the surface. 0.0 means no scattering, 1.0 means full scattering. With a non-metallic object it is the glossy reflection. Note that glossy reflection is not the same as how a mirror works.
The following has on the left a sphere with roughness 0.0, clearcoat 0.0. On the right you have a sphere with roughness 1.0, clearcoat 1.0 and clearcoat roughness 0.0. You can see that the sphere on the right now has also a hint of environment reflecting in its clearcoat layer.
when i change the lights, either emission strength or light strength or similar when raytraced is active it often if not always happens that it deactivates the lights and switches to default light, then i found the only way out is to switch to rendered mode for short and reinitiate raytraced viewport.
As a curiosity I did a direct comparison between Cycles and a full caustics renderer like Bella. Turns out cycles is pretty darn good. You do get more indirect bounces inside the sapphire with Bella, so there is a little more vibrancy there, but overall close.
Unfortunately, the expect methods weren't failing the the tests were passing regardless of what the text was that I passed into queryByText. Feeling slightly frustrated, I set out to find a way to test for an empty component and settled on the following solution:
Everyone, unfortunately.
For the last few years Mac's ram has not been user-changeable. Soldered to the logic board. And now with M-chips, the ram is part of the actual chip. That's part of what makes them so fast. But the ram size is locked in at purchase, impossible to ever change unless you've got some pretty sophisticated equipment, if possible even then. We're not talking repair shop stuff here.
but based on this table - m2 pro mini may just be what I need and looks to be a great balance /performance - I only do private residential extensions (vw 3d/bim) and exports to twinmotion 3ds. (So nothing too big really (
Looking at the table, it's pretty clear that with CPU rendering like FQRW / Cinema, the number of cores is the biggest factor (which we've known forever). As I've said elsewhere, based on my experience with this M1 Ultra, the gains from increasing 12 to 20 cores are almost exclusively with RW. I got this Studio for FQRW. If I ever decide I don't need FQRW / Custom RW, I'll happily replace it with a M2 MBP.
I'm waiting for the Mac Studio M2, to see how the base model compares to a fully loaded Mini M2 pro. I would prefer the Studio for the bigger cooler, it might help against throttling with Cpu intensive tasks.
Please render at 960 * 540 resolution, and please keep the render times around 3 minutes (longer if your machine is significantly older/less powerful)!!. Quote your hardware as well as the engine you used, as well as any settings, like my example above.
The scene has materials with names showing what that material should be. Please try balance the lighting to the image I posted as reference.
.Blend here BlankComparisonScene.blend (99.8 KB)
Here is the floor texture. =33550
Here is the HDRi. =355
Hi bashi, it is hard to compare render engines when you render double as long and with half size.
Please add also your system specs.
As far I can see it is very clear in foreground but not in mirror, hm.
I never test Mitsuba because cant built it on my system but follow the development still.
@Repgahroll, looks really good, in case of your system and time seams the best.
@bashi, cool, nearly noise free but caustics looks better with your first render.
Has Mitsuba not also VCM like SLG3, as far as I know the SLG3 VCM comes partly from Mitsuba.
First try with Cycles, it seams it is not possible with Cycles to get it because of Pathtraycing only atm.
Does not matter point light or mesh emitter.
Full GI
1500 Samples
3.27 Minutes
GPU
Specs in my signature.