Falagard wrote:I know how SpeedTree works, I've spent months with it, and implemented my own unique version similar to it, remember?
Yeah, that's me trying to teach your GrandMother to suck eggs.. Sorry.
Thank you for explaining how SpeedTree works. From watching OldBlivion I was able to see it in action. And I don't think it should be a problem when using billboard clouds, because as far as I can see, there's no animating leaves on but up close.
Well, I guess we are waiting for a live demo of it in action.
<edit> fronds must be another name for billboard clouds, right?
</edit>
/* Less noise. More signal. */ Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion. OgreAddons - the Ogre code suppository.
The texture billboard cloud generation is done using ogre, a render system and render texture, that is why its not important if you render your original tree with shaders or not
I'm having lots of problems with SpeedTree tree style rendering for various reasons and would prefer to avoid them so this billboard cloud solution is very interesting.
Not to hijack this thread, but I hope these problems point out some of the benefits of using billboard clouds for the leaves:
1. Lower end hardware without vertex shader support - means you have to create two different versions of the same tree if you want to support older hardware.
2. Lighting quads that face the camera is a problem, since they are facing the camera the lighting is wrong.
3. Shadows cast from quads that face the camera is a problem, especially since my current implementation isn't done using a custom movable object factory and only works with a single camera, meaning the quads are oriented towards one camera each frame and don't work with any number of cameras that might render that tree from different directions. Can fix but takes work.
Billboard clouds won't have some of these problems though lighting will still be a bit of an issue.
The texture billboard cloud generation is done using ogre, a render system and render texture, that is why its not important if you render your original tree with shaders or not
Thanks for the answer, that clears things up a lot. What if the extents of the billboard cloud are calculated by going through all the verts in the original mesh and finding min and max values of the vertex positions, but I'm positioning the verts in my shader and the positions in the actual vertex data of the mesh is not the final position that is rendered on screen?
We use the simplified models as static levels-of-detail in the medium to far field.
Ah crap that means that I was wrong about seeing billboard layers for the trunk when I freeze framed it - it must have been really low lod trunk mesh then.
*edit* although I just watched the second video and I swear you can see the cross sectioned tree trunk.
Probably when they say "we use simplified models as lods" they refer to billboard clouds with different error threshold to produce the level of detail model
I dont know the exact method they might be using in that video, but the proposed algorithm suggests using the error threshold and the texture resolution to produce the lods
The trunk is created using a "Card Board Plane", so what you have watched in the video is probably correct, although i dont see a reason why you cant use the real geometry for the trunk if you want and dont generate the card boar plane, with little modifications
I must have been tired when I posted these. I re-read the page and he's definitely just saying that they generated simplified models using billboard clouds and use them as levels of detail for distant trees, which implies that you wouldn't use them for near viewing.
He doesn't say that he's using full meshes for near viewing in the video demo, and the video shows that he's not.
fronds must be another name for billboard clouds, right?
Not at all. As SuprChickn stated, fronds in SpeedTree are used for Palm tree type leaves that don't face the camera, for ferns, etc. but also used for fake branch geometry. They don't do dozens of cross sectioned quads for a fronds, it's usually just a few polys.
In my tutorial on how to create trees for GOOF (which as you might know, I've pulled trees out of GOOF so far because of the aforementioned problems) take a look at this picture:
I'm just gonna post a small progress report. I'm currently working on implementing the more complex plane selector. There are a lot of things needed for it to work properly, and it's very easy to make some silly error that costs several hours of debugging, but I'll hopefully have it working before the end of the week. Then I need to optimize it, add some different plane modifiers and clean up the code. I'll also add generation of heightmaps for the billboards so that more complex bumpmapping techniques can be used
An update: The billboard cloud generator is basically complete, there's mostly more optimization thats needs to be done, but the generator should work now. Any comments on the interface would be appreciated. I might add so that it can work with existing Ogre roots instead of creating its own if people want it, but since the generation is so time consuming, so I dont really see how it could be integrated into other tools in some good way, so perhaps its best to use it as a stand along command line tool?
I'm thinking about adding support for tree models that have their leaves assigned to various stems in the tree, probably using some sort of xml format. This would allow the creation of billboard clouds that could be used in combination with tree animation. But this will have to be something I do after the summer of code is completed. But since I'll probably use this tool myself, I'll continue updating it even if I dont get money for it
Assaf Raman: The generator is really slow now since I haven't added the custom memory allocator yet. So expect to wait 15-20min for models like that Anyway, the newest version has working support for listeners, so you're notified when the generator changes phase and when planes are selected, so you can keep track on the number of faces left to simplify.
My wavefront .obj loader doesnt support multiple materials per object, so the textures for that tree wont be correct... I'm gonna try to fix this tomorrow.
I'll try to start working on some kind of help file or tutorial once I've got the .obj files working properly. The parameters to the generator makes a huge difference both in terms of generation speed and in quality of the output model.
Do I need to use different settings in the project?
