Hi, again =)
Does Lavina support an opacity map from Forest Pack trees?
Thank you.
Best regards,
Andrew.
We don’t support opacity.
The issue with opacity is that it’s not accelerated by the RT cores.
When a ray hits an opacity mapped leaf, we have to sample the opacity texture to figure out if there is an actual leaf there or not.
And this texture fetch is not accelerated by the RT core.
Even a single ray may have to go through many such intersections until it hits a part of a leaf that’s not cut out by the texture.
We recommend using actual geometry, where the leaf is made from a larger number of polygons with the correct shape.
Greetings,
Vladimir Nedev
Hi, Vladimir.
Oh =) If every leaf will be a geometry object… Will Lavina handle so many polygons if I create a forest with these HQ trees on my 2x2080TI with NVLink?
Thank you.
Best regards,
Andrew.
Without a problem.
Just a note first, Lavina doesn’t support NVLink.
And, yes, we believe that having more geometry in the leafs will be faster than using opacity maps.
We will probably have to confirm this in the future with some actual tests.
More geometry means slower rendering however, there is no way around this.
For best performance, you will want to keep the triangle count as low as possible.
Of course, if performance is already satisfactory on your scenes, you can leave them unchanged.
The fully ray traced nature of Lavina, makes it very efficient at handling many instances (like trees) where each instance has lots of geometry.
A rasterizer (like 3dsMax’s or Maya’s DirectX/OpenGL viewports or the Unreal/Unity game engines) requires a lot of complex optimizations to handle this since each instance of a triangle has to be iterated over each frame,
even if the triangle doesn’t contribute a single pixel on the screen.
These optimizations include geometry with different level of detail based on distance, and culling of whole instances based on whether they are within the perspective frustum.
These optimizations still break for certain scenarios, and that’s why environments are often represented as bounding boxes.
Greetings,
Vladimir Nedev
hm, i like very much hwat i tested in lavina so far, (love it, great start!)
but not planing to add opacity maps is a problem for most archviz scenes. we want to export scenes that we also use in vray for offline rendering then. not being able to use opacity map cutouts on materials might be some trouble. i hope you will find a solution for that. i hope even if slower it can be added as option at a later point,
Ok. I will test the trees with leaf geometry =)
Today I tested 135 million polys =) One big cliffs geometry from World Creator =) 3dsmax have 60 - 90 FPS with this geometry. I tried to export it to .vrscene and then opened in Lavina =) And had a crash.. So the question is - how many polys or tris we can upload to Lavina? =)
This is a video with an issue → https://youtu.be/4TupsWsMIAk
This is test in 3ds max → https://youtu.be/H2CjRhuFtsc
Link to DMP file → http://bit.ly/37usJE0
Thank you.
Best regards,
Andrew.
How did you pack 135mil poly into 3GB?
A 25mil poly terrain is 1.5GB as vrmesh (identical to vrscene for size.).
Are you sure that file is fine?
F.e., does it load back into max?
Today I tested 135 million polys =) One big cliffs geometry from World Creator =) 3dsmax have 60 - 90 FPS with this geometry. I tried to export it to .vrscene and then opened in Lavina =) And had a crash.. So the question is - how many polys or tris we can upload to Lavina? =)
The crash happens because we don’t handle out of memory conditions for now.
You will be able to fit less triangles compared to a rasterizer, because in addition to vertex positions, normals and UVs, a ray tracer has to store the triangle acceleration structure as well.
How many exactly, depends on your free GPU memory (which can be taken by other applications, including 3ds Max running in the background) as well as the mesh topology.
I would expect roughly 1GB per 15 million triangles, based on some quick tests, but it could be less or more.
Slightly less than half of this size is the acceleration structure.
Note that initially the acceleration structure is built uncompacted and takes roughly twice as much memory, so the overall memory requirement while loading is ~50% more than the final value.
So around 1.5GB per 15 million triangles while loading.
There is also some additional scratch memory that has to be allocated while building the acceleration structure.
This is done by RTX and I haven’t tested how much it is.
If you have more smaller meshes, instead of one huge one, the memory spike caused by this scratch buffer will be significantly less.
Greetings,
Vladimir Nedev
I will log an issue to improve the loading of very large meshes, like your terrain example.
We would need to split the mesh into smaller ones and make sure that the acceleration structure for each one is compacted before we start building the next one.
This will reduce the memory spike while loading, and hopefully get you ~15 million triangles per 1 GB.
Greetings,
Vladimir Nedev
From what I’ve heard from Vlado, V-Ray would also render faster if you use actual geometry for the leafs instead of using opacity maps.
Greetings,
Vladimir Nedev
It’s been like this since forever, and not just with V-Ray.
I have yet to hear of *any* raytracer which is quick with opacity.
“From what I’ve heard from Vlado, V-Ray would also render faster if you use actual geometry for the leafs instead of using opacity maps.”
yes a bit, but since vray has the stochastic opacity map this is neglectical, and most trees available use that, and also many architectural materials like metal meshes do need opacity maps.
you cannot model a million wholes in a metal mesh sheet p.e
so if that tool is meant to be also used for architectural rendering, support for opacity woudl be very important, even if this is a small speedhi t(maybe with the way vray uses it, stochatic mode etc)
@charlyxxx and @vladimir.nedev : so i made a 100 mil tris terrain (made in houdini, with erosion, so to take topology-dependency out of the equation) VRScene file, and it’s 5GB on disk.
In the video Charly posted his file is ~3GB, which sounds unfeasible, as it ought to be around 7.5GB instead.
Also, loading the file here is taking several minutes, and this all before the VRAM is occupied, it’s all two-core CPU action and System RAM, so the video posted by Charly couldn’t have possibly gone out of VRAM in such a short time.
I maintain this isn’t a memory error due to polycount, irrespective of Lavina having the proper checks in place.
Charly, could you maybe share the scene file in question?
@ Lele: "Technically, you can.
Just as you can model individual leaves on trees, and exact, complex cutout shapes."
Lele i do archviz since 1997, and believe me no 3d app can cope with the amount of modelled mesh holes in any real world scene;)
vray or lavina might be able to render it, but the host app dies long before and gets unusable due the size and speed of the model then.
it cant be done was meant as “it cant be used in production scenes”, there is simply not a time for such a thing as archviz is always within short time frames.
this is also about work flow, which should be easy, and as far i understand it should be compatible to vray scenes.
anyway as said here and on linked in, love the start of lavina, it feels great, i am looking for forward to it, and hope opacity cutout maps will make it in somehow in future.
How did you pack 135mil poly into 3GB?
A 25mil poly terrain is 1.5GB as vrmesh (identical to vrscene for size.).
Are you sure that file is fine?
F.e., does it load back into max?
Hi, @_Lele
I don’t know =) I’m not a technical artist =) I just click on “Export to .vrscene and get this file”
This is a test video with this file → https://youtu.be/H2CjRhuFtsc
This is another video with .vrscene import to 3ds Max - https://youtu.be/EIP7fy6iskc
As you can see - 3ds Max + V-Ray can read this file =)
In the video Charly posted his file is ~3GB, which sounds unfeasible, as it ought to be around 7.5GB instead.
I created this terrain in World Creator 2. Not in Houdini. With many filters.
Also, loading the file here is taking several minutes, and this all before the VRAM is occupied, it’s all two-core CPU action and System RAM, so the video posted by Charly couldn’t have possibly gone out of VRAM in such a short time.
But this is no a fake =) I really recorded this video =) This is not a AI recording =) ahhaha =)
I maintain this isn’t a memory error due to polycount, irrespective of Lavina having the proper checks in place.
Ok we should check this. What I can do?
Charly, could you maybe share the scene file in question?
Yes, I can.
Here is a link to it → http://bit.ly/2P1jQuY
When you will download it. Let me know.
I will log an issue to improve the loading of very large meshes, like your terrain example.
We would need to split the mesh into smaller ones and make sure that the acceleration structure for each one is compacted before we start building the next one.
This will reduce the memory spike while loading, and hopefully get you ~15 million triangles per 1 GB.
​​​​​​​Hi @vladimir.nedev
Thank you very much for this detailed answer.
From what I’ve heard from Vlado, V-Ray would also render faster if you use actual geometry for the leaves instead of using opacity maps.
So, as I understand, render trees with triangulated leaves in 3ds Max is better too? =) And in Maya and etc.. with V-Ray.
Thank you and have a great day.
Best regards,
Andrew
I opened the .dmp file Andrew shared. The crash happened while processing a viewport mouse wheel event. I was able to easily reproduce it by loading a large scene and scrolling the mouse. We will fix this.
When you will download it. Let me know.
I downloaded the scene, thank you.
Greetings,
Vladimir Nedev