good LOD plugin for C4D

Hello
Continuing on the path of discovery, I found a great pugin called SimpleMaker Pro for Cinema 4D which does poly reduction but keeps the uv map intact, I think this could be a pretty impressive tool for LOD trees!
The tree is the same one I posted but with Sycamore bark/leaves. Not the right shape for a Sycamore but good to do for a test. I think I will start being specific about species now...
Boxy

 

http://forum.otee.dk/viewtopic.php?t=789

Yup it's a great tool Jeff

 

Holy.... Nice....

 

That looks really nice.

If anyone has a thought on the algorithm for an initial LOD system for this, I could take a shot at implementing it if it is not too gigantic of an undertaking.

All I could think is to check the squared distance with the camera and change the mesh each update frame dependent on the distance. That seems like it'd be very slow.

That leads into an idea where there would be multiple spherical trigger colliders attached to the camera. Then using the TriggerEnter and TriggerExit you'd give the trees the LOD messages. Then hopefully this is optimized in the physics engine...

-Jon

 

Modern begetation rendering is all about one thing: minimizing draw calls. GFX cards can handle a ridiculous number of polygons, but only relatively few draw calls per frame. Hence the trick is to render 10-1000 trees in one call.

The LOD-system would AFAICS be comprised of the following steps:

Billboarded versions of the trees for long-distance rendering. Preferably rendered into one huge texture, then rendered using a specialised vertex stream and vertex program... Think particles on the GPU. This would enable us to easily render 500 distant trees in one call.

As we get in closer, clumping is the order of the day; specialized vertex streams. Each stream contains, say, 10 copies of a tree but with different bone indices for each tree. Rendering 10 trees would then effectively mean loading up 10 bone matrices, then doing one render for 10 trees. This would scale from 2 trees per draw call up to 50-60 trees.

In the closest version, we render trees one at a time like normal game objects.

The first two versions will require some special code from our side to help out with the rendering. What you _could_ do now, though would be to implement the hierachy for the rendering - a quadtree based approach is the order of the day. So something where we can get a list of trees within an area. Each LOD contains 4x as many trees as the lod below it. Later on the lod classes would own the rendering structures.

The other part is looking at some vertex shaders that does the particle geometry. Not too hard, really...

I honestly think that it is a bit premature for this, though...[/img][/b]

 

That's a very interesting approach... I agree that something like that would be best delayed.

So that means delayed until there are a bunch of beautiful trees to work with.

In the mean time, maybe a few simple scripts to test how well the LOD work in transition?

-Jon

 

Thing is: we need to expose some of the gritty details of the LodMesh class for you. You could start doing all the boring housekeeping, though...

But yeah - getting the complete LOD selection for a single tree would be very helpful as well....

 

We will make that a priority then. Do you have any suggestions how many levels there should be? Jeff

 

Not sure, really...

Try to have each lower LOD have 25% to 50% of the higher lod, though... Keep going until it doesn't make sense... There are some other tricks that can be applied below 100 polies, so doesn't make sense to go there....

 

Nice one, we'll try and get a complete LOD set done asap, though I am in the process of moving this week so as and when. Thanks for keeping the ball rolling folks.
Boxy

 

I believe that is called being fashionably late hehe

 

Hey Boxy - that tree is looking great!

R.

 

Thanks Richard. Hopefully that is just the start. It suddenly occured to me that actually I don't need to find a quick solution for the highest LOD version and I should literally make each branch cluster a unique shape. As long as they're all using the same UV map... then I can specifically copy the shape of the reference trees we gather.
Boxy