Wavefront Object importer and exporter.
Simpler plane selector.
Texture packing using bsp trees.
Various image resizing tools.
Various helper functions for the more complex plane selector that will be implemented later.
Function for calculating a tight fit rectangle for a set of points.
Various math functions missing in Ogre (like fromToRotationMatrix in my code).
I'm currently working on getting Ogre to actually do any rendering so that I can generate textures for the billboards. Once I've managed to do that, the library is functional in the sense that it can import a wavefront object, create billboards, texture and normalmap and export it as a wavefront object and some image files that can be used.
I will then clean up the interface and code a little and start on the more complex plane selector, which I reckon will take most of the time that's left since there are a lot of things needed for it to work and not take too long time to finish.
Pics of a simplified tree mesh from various angles. The number of planes is dependent on the specified error value specified so simplified models dont have to have this many billboards. The more complex algorithm will probably give better billboards.
Packing (will probably implement a better algorithm later):
I noticed some very interesting commits to the ogreaddons repository lately, and wondered when you'll post some progress about it, and now you do!
Will this allow you to dynamically change LOD, like switching to the full mesh when up very close, and removing billboards from the cloud as the tree fades into the horizon?
Or is that left as an exercise for later?
Looks very promising! And really looking forward to see some textured Ogre rendered billboard cloud trees!
/* Less noise. More signal. */ Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion. OgreAddons - the Ogre code suppository.
seems really interresting especially the packing algorithm which seems to give a somewhow optimized result. Can u tell me how the packing algorithm work if it's not much? (basic principle) --Sorry, but I m tempted by sexy algorithms
farakon wrote:Can u tell me how the packing algorithm work if it's not much? (basic principle) --Sorry, but I m tempted by sexy algorithms
Looks like a tree based box packer to me In fact he mentions "Texture packing using bsp trees. " Probably something like this: http://www.blackpawn.com/texts/lightmaps/ . Not that complex but if you can guarantee your textures are rectangular it works really well.
Heh, interesting timing. I have been chatting with the author (Frank Kane... Cool name eh?) of SilverLining about a free for non-commercial use license option.
Will this allow you to dynamically change LOD, like switching to the full mesh when up very close, and removing billboards from the cloud as the tree fades into the horizon?
Or is that left as an exercise for later?
Adding LOD levels should be very easy, as this is produced by varying the error threshold parameter (as suggested by swx), using the current lod as the input for the next
Additionally, texture resolution can be part of the lods system
But the first iteration should focus on correctly generating the billboards
swx: i did a fast review of the code commits of today, seems you are locking the pixelbuffer returned by the renderTexture, you should use "blitToMemory" when using renderTextures, as they are not lockable (on some machines locking works, but not on others)
Nice.
Why wavefront ".obj" and not Ogre ".mesh" ? is it a limitation of Ogre Format ?
"Texture packing using bsp trees." : interesting !
I used a very fast quadtree packer (limited to square) in my dynamic impostor code. I wonder how fast bsp insertion/removing would be ?
@sinbad: If fast enough perhaps that could go into Ogre Core ?
It could allow using a single Render Texture but for multiples viewport transparently for user ?
At term it could also be used to do some automatic cheap "Atlas" packing (static geometry, instancing) maximizing their speed ?
btw, here's new paper on lod level and bbclouds for foliage which is worth reading.
He's probably using the .obj format because Blender has excellent Wavefront support.
I can see that he's testing it in Blender.
The Ogre mesh importer is not stable enough.
/* Less noise. More signal. */ Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion. OgreAddons - the Ogre code suppository.
tuan kuranes: that's the algorithm I use for the plane selector.
sinbad: yeah, thats the lightmap packing algorithm I use.
tuan kuranes: I use wavefront object files since it has importers and exporters to every 3d editor known to man
Multiple LOD levels could probably be created by using the previous billboard cloud, but I doubt that the result will be very good... Its probably better to build from scratch using a larger error value.
swx wrote:Multiple LOD levels could probably be created by using the previous billboard cloud, but I doubt that the result will be very good... Its probably better to build from scratch using a larger error value.
Isn't the LOD calculated at the creation of the Ogre Mesh file as well? So would the swap into bbclouds happen automatically like the change in LOD's?
Just a quick update. I've got basic texturing working, but still have some things I want to fix before I post any new screens. Hopefully I'll have something new to show tomorrow
I'm working on integrating normalmap generation, I'll hopefully have some screens tomorrow. Had to do a lot of bug fixing the last couple of days, that's why I havent posted any new screens
I'm also trying to clean up the code and interfaces since I really hate ugly code
So if I understand correctly this technique is good for things like generating a representation of a mesh that will be used as one of its LOD levels when far away from the mesh. So close up you'd use the actual mesh and further back you'd switch to the billboard cloud?
An example would be a maple tree. When close you have full geometry for trunk and leaves, when further back you switch to billboard cloud.
Can this work with something tricky like this situation:
Imagine I have a vertex program that renders tree leaves so they always face the camera, similar to SpeedTree. Can you generate a billboard cloud from this mesh - even though the geometry is actually positioned in a vertex program? I know this is a bit of a tricky situation and I'm just curious. You must be doing something like determining the cross sections based on the vertices of the original mesh, and then doing render to texture for the textures applied to the billboard cloud.
Im sure users will be very impressed with the results
So if I understand correctly this technique is good for things like generating a representation of a mesh that will be used as one of its LOD levels when far away from the mesh. So close up you'd use the actual mesh and further back you'd switch to the billboard cloud?
That is probably no necessary, a billboard cloud can be used as the full resolution level of detail, and lower res version of the same billboard cloud or lower resolution billboard cloud versions of the original model should be used at the lods
Take a look at this video to have an idea of their use, all the 150.000 trees are billboard clouds, and just frustum culling is used as the culling process
Bull, unless I see a demo of that in action instead of a blurry video, I can't imagine anyone walking up to a tree trunk within a few feet and being fooled by a billboard cloud. You can even freeze frame that video as he's at the closest to the trees and see the billboard separation of the trunk. Now, I can see the billboard cloud being used for the leaves at all times, so maybe if this thing works as well as it looks, I'd toss out my whole leaf rendering code and use billboard clouds instead for the leaves at all times, while displaying a full mesh trunk while close up, Then use billboard cloud for a lower LOD.
It did look very impressive for large forest rendering, and would fit in extremely nicely with a high resolution tree generated with Arbaro / MeshTree where there are far too many leaves to be rendered in realtime. I just don't think the trunk will fool anyone close up.
My question about vertex programs is still definitely relevant and here's why:
Let's pretend that the billboard cloud doesn't fool a user close up, or that I want to continue using SpeedTree type solution when close because I like how it looks, the leaves can flutter nicely, or whatever, then you're going to have to create a real mesh representation of the tree and leaves for in game, and only use the billboard cloud for a lower level of detail. During the content creation process you're going to be creating trees that work with SpeedTree style rendering where it's a collection of camera oriented quads. If you're going to be switching LODs from the SpeedTree style leaf rendering to billboard cloud rendering you're going to want them to match up fairly closely. Of course the billboard cloud calculation is going to be done offline, but is it done using Ogre and render to texture, or done with some other technique that doesn't even require a render system at all? If it's done using Ogre and render to texture then it might be possible to actually render the tree into the billboard cloud using the same technique (vertex shader) as when it's displayed in game, so when you switch LODs it looks very similar.
Clay
Last edited by Falagard on Wed Jul 05, 2006 4:11 am, edited 1 time in total.
Falagard wrote:Bull, unless I see a demo of that in action instead of a blurry video, I can't imagine anyone walking up to a tree within a few feet and being fooled by a billboard cloud.
Billboard clouds are not supposed to be viewed up close.
That's not the way SpeedTree is handling it either. That's handled by LOD.
Try and run Oblivion through OldBlivion and you can see what goes on behind the scenes.
/* Less noise. More signal. */ Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion. OgreAddons - the Ogre code suppository.
That's what I'm saying dude, but not what Lioric said.
a billboard cloud can be used as the full resolution level of detail
Also, I don't know what you mean by this:
That's not the way SpeedTree is handling it either. That's handled by LOD.
I know how SpeedTree works, I've spent months with it, and implemented my own unique version similar to it, remember?
SpeedTree uses camera oriented quads for the leaves when close up, a mesh representation of the trunk close up, then a lesser number of camera oriented quads for further away, but they are scaled larger, and a lower resolution mesh for the trunk, etc. for several levels of detail, finally a single camera oriented billboard for the lowest level of detail. They also use "fronds" which are quads that don't face the camera and are used for fake branches.
