Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] Daily Builds => Topic started by: hubrobin on 2015-07-17, 15:55:37
-
Hey guys,
in order to add adaptivity, filtering and "keep edges together" features to our displacement we had to completely redo it's implementation. It would be awesome if you could give it a shot and give us some feedback on it, so that we can fix all the potential bugs before the official release of 1.2.
Thanks!
Robin
-
Just got my hands on this huge new build. Did a couple quick tests with new displacement. Very first impressions:
- it has issues with bercon noise.
- looks like adaptive mode gives inferior results in comparison with non adaptive
Overall, adaptivity looks mighty impressive.
p.s. since i have no experience with vray, i have no clue what's a purpose of CoronaDisplacementModifier. When should i use it?
-
Loaded recent scene with not so heavy displacement and new build just run out of memory, whereas older build has no problem at all. But i guess it should go to mantis, right?
Edit: increased displacement screen size from 1 to 2.5 to get approx the same amount of pollys as in older build and scene renders fine. New displacement gives a lot cleaner result in that particular scene! Unfortunately seems like max subdivs per poly isn't working at all.
-
yes, max subdivs is not working and will be removed. please report crashes in mantis ;))
-
May I ask why not? What is determining subdivisions in the new algorithm? If i plug in a very noisy displacement map I easily make adaptivity useless, thus producing lots of faces.
-
I did some displacement tests on Emily.
I can render the image up to 1200px. When I try to render with a higher resolution 3dsmax crashes after a minute or two. I can't see any artifacts or difference when I enable/disable Adaptive.
I thought it was weird that my PC couldn't render the image larger then 1200px, so I fired up V-Ray. In V-Ray I can render the image with 12 000px just fine. But when the image size gets above 6000px, V-Ray begin to cache to the HDD. (I only have 16GB ram on this particular PC).
The problem with Corona is that it caps my RAM when calculating displacement, before the render begins. Corona is using 12GB RAM when calculating displacement, and then 6GB RAM when rendering. While V-Ray has the same 6GB RAM usage throughout the whole process.
I have uploaded some comparison pictures and CPU/RAM overview if people are interested. This is not a who is best comparison.
The V-Ray render is 0.5px displacement, and the Corona is 0.8px because it crashed on lower settings.
-
Removing of Max subdivs seems very strange indeed. Unless there'll be a better alternative to tame down hungry displacement. Increase in RAM usage during displacement calculation phase, makes displacement much less capable then it could be, i hope it'll be fixed.
Anyway did some comparison with old displacement. It seems like RAM usage is more or less the same (except big spike during calc phase). Processing time is noticeable longer. Displacement quality... well, that's quite interesting. At low settings it seems like new displacement does a lot better job - artifact free and smooth result. But at higher settings i prefer old one more. New displacement strugles to produce nice crisp result. But those impressions are based on one scene, so things may change after more testing :]
Here's some gifs:
Low:
(http://s16.postimg.org/lg3s19ts5/low.gif)
Medium:
(http://s16.postimg.org/6vmp6fyth/medium.gif)
High:
(http://s16.postimg.org/fgg0xm8zp/high.gif)
Ultra:
(http://s16.postimg.org/iokianv9h/ultra.gif)
Edit: fixed links
-
the new displacement filters textures - try disabling texture filtering to see if the results change
-
OMG, you're right. Disabled filtering and results totally rocks! New displacement needs so much less polygons to render same quality in comparison with old one, it's just ridiculous. Now if that RAM usage spike could be fixed...
BTW, what about CoronaDisplacementModifier? Can someone explain me why it's needed?
-
I think the parsing should be fixed as well. In case it's not possible to get back to old parsing speed, then i would at least prefer to have option to choose between new and old displacement. While old one had breaking edges and no adaptivity, it did not take ages to parse. For something like dirt ground where you don't need adaptivity and don't need to have separate smoothing group, old one was significantly better.
-
OMG, you're right. Disabled filtering and results totally rocks! New displacement needs so much less polygons to render same quality in comparison with old one, it's just ridiculous. Now if that RAM usage spike could be fixed...
BTW, what about CoronaDisplacementModifier? Can someone explain me why it's needed?
I guess it's to make displacement independent from materials so you can have different objects with different materials use one modifier for the same displacement map. Didn't test, but that's what I expect based on how it works in other renderers.
-
Thanks for taking the time for testing and providing the valuable feedback! I will address the memory consumption as the first thing on Monday and I believe that I will be able to get rid of the most of the overhead. In terms of the result the algorithm provides it seems that we might be on a good way. I will elaborate on all the other stuff you came over once I have discussed them within the team on Monday.
Thanks again.
-
Yep, out of memory (pc freezes) here too with without even using a high subdiv value ( size 1 instead of 2 / 300subdv )
Continuity is very nice thanks a lot !
-
OMG, you're right. Disabled filtering and results totally rocks! New displacement needs so much less polygons to render same quality in comparison with old one, it's just ridiculous. Now if that RAM usage spike could be fixed...
BTW, what about CoronaDisplacementModifier? Can someone explain me why it's needed?
I guess it's to make displacement independent from materials so you can have different objects with different materials use one modifier for the same displacement map. Didn't test, but that's what I expect based on how it works in other renderers.
Now it makes sense. Thank you!
-
- it has issues with bercon noise.
Can you be more specific on this topic? Was it also caused by filtering?[/list]
-
I'll try to conduct more detailed feedback on that issue a bit later.
-
Indeed bercoin noise as well as native noise at default filtering strength works very unreliable as displacement maps. Lowering filtering to minimum seems to solve it.
BTW, got a crash when pluging beron noise in displacement while IR was running. Attaching minidump, maybe you'll find it useful.
-
Build jul 21
- Displacement filtering not working. Changing filtering blur affects only subdivision pattern, but displacement itself remains the same no matter blur value.
- Displacement produces kinda faceted result. See attached pic.
Is it known issues or should i start filling mantis report?
-
Hi,
1. We have disabled the filtering in case of displacement to match the old behaviour for now.
2. That looks weird indeed. Can you fill in a Mantis report and provide me with the data?
Thanks a lot,
Robin
-
Done!
-
I tried the latest Daily Build with Emily, 1px displacement.
The 1200px render is much more stable, it never goes above 6.2GB RAM (Last daily used 12.2GB) . The precomputing was much faster as well.
But when I try to render the 6000px version, 3dsmax still crashes. My first render test ended with a complete PC freeze, waited for 15 min and took a force shutdown. On the second test I got like 10 windows with "Halt! Exceptiontime!". I waited 15 min but nothing happened, had to force close 3dsmax. I took the time v-ray used to calculate before it began rendering and it was 18 sec, so I could have something to base my waiting time on.
-
were you able to render the 6000px 1px displacement with 1.1?
-
Could it be that some kind of max subdivisions bound took place in case of vray?
-
I wiped the scene settings and started over. This time with 4px displacement, going to test with 1px again later.
Both V-Ray and Corona took around 16 sec to calculate the displacement.
Both render engines were stable!
Both render engines were laying around 7.5gb ram.
I couldn't find any subdiv option in Corona Options, have you guys removed it ?
The first Corona render with only CoronaDisplacementMod turned out very low poly, and the skin pores got stretched all over the place. Just look under and around her eyes.
The second Corona render is using MeshSmooth modifier with default settings, I noticed that CoronaDisplacementMod subdivided the mesh by itself when it was above the MeshSmooth modifier. The mesh got less ploys when I turned off the light bulb on CoronaDisplacementMod.
The result looks very good, nice round chin and nose, the stretched pore problem is gone. But the 16k micro displacement map is not showing up because of the 4px displacement.
I have included the render images from both engines (About 10min render time each).
I have also included some screenshots of the settings I used. Remember that V-rays modifier overwrites the default settings.
Good job on the last Daily build guys. Just love Corona :)
EDIT: 1px ended in complete freeze, had to force restart the pc.
were you able to render the 6000px 1px displacement with 1.1?
I haven't tried with 1.1, got the head from wikihuman a couple of days ago.
Could it be that some kind of max subdivisions bound took place in case of vray?
Is it because I can force v-ray to 8 subdivs and 0.001px that v-ray works ? The pore details are so much better this way.
-
Just one quick hint. Vray (as well as Arnold) automatically creates normal map out of displacement map in areas where there is not enough subdivision detail. In Corona, you can do the same by simply plugging displacement map also in a bump slot. Relying solely on displacement to give you 100% of the detail is often nearly impossible.
-
There's quite clearly visible line seen where subdivision gets lower when screen size mode is used. In attached picture is shown comparison between world size (left) and screen size (right). Maybe some kind of treshold spinner could be introduced in CoronaDisplacementModifier to allow user to fine tune when adaptivity kicks in?
-
There's quite clearly visible line seen where subdivision gets lower when screen size mode is used. In attached picture is shown comparison between world size (left) and screen size (right). Maybe some kind of treshold spinner could be introduced in CoronaDisplacementModifier to allow user to fine tune when adaptivity kicks in?
Hopefully not, it's horrifying idea to have spinners for fine tuning bugs. That's probably something to do with filtering. It has been messed with in latest builds. Also, the displacement map used on your picture is prime example of a map where you would not wan't to use adaptivity at all.
-
Well if it's a bug and it will be adressed, than it's even better :]
One more question, though. Why do you guys opted to non smoothed polygons output after displacement? Or it is temporary too?
-
It was done the way it had too high memory consumption. I will put in more efficient solution by tomorrow.
-
Well if it's a bug and it will be adressed, than it's even better :]
One more question, though. Why do you guys opted to non smoothed polygons output after displacement? Or it is temporary too?
The new displacement respects base object smoothing. At least the version i tested while ago. Faceted result of your render is caused by bug in Noise map in Max 2015. The exact same scene will render fine and not faceted in Max 2015+. You can also observe same bug in Smoke map, that has not been fixed even in latest 3ds Max.
-
I was asking about smoothing, not faceted noise bug, but if you say it's working fine i latest build, then i'll wait for it to become available for us mortals :]
-
Yep, smoothing worked, but i tested it like a week ago, something may have changed since then. I will ask Orbin tomorrow.
-
I began making the SSS shader for Corona today, it's easier to see the displacement now. I can push it down to 3px before my computer freeze.
The SSS shader is still very rough, but it's good enough for displacement previewing.
-
There's clearly visible polygon edges in your Corona render (ear, chin). Can you render with grey material to see if it's made by displacement or by SSS?
-
There's clearly visible polygon edges in your Corona render (ear, chin). Can you render with grey material to see if it's made by displacement or by SSS?
That's from the SSS, it's only 2 passes. Here is the SSS element. It's gone in my latest version.
It's very time consuming to make these "hollywood" skin shaders in Corona right now. I have to render all the different Elements separate and (Add) them together in Photoshop 32bit. Would be great if we could get a Shellac/additive blend mode. But this is kinda off topic ;)