zimluura Wrote:just to clarify: the trees and destructable environments were supposed to look like sub-entry of the "shared object library" heading.
Shared object library isn't a bad idea, it's not much different from what we have now except it would get objects for tracks from somewhere besides the track objects.
Maybe we should try to get support for objects on the track that can be moved by the cars, and work from there. For instance, the cones don't move when you run over them. AutoX mode would be a lot better with movable cones. Once that's done, it wouldn't be hard to move from there to stacks of tires. For now, we can just put a flag in list.txt for the track objects to tell which objects are movable.
If someone who knows C++ dedicated a weekend to this I bet it would be done pretty easily - the support for model loading is already done, and trimesh-trimesh collisions are already done for cars and track objects marked as collidable. Most important would be to add support for collisions between the track objects and other track objects.
zimluura Wrote:so for the trees i was thinking still have them be 3d modeled. just not storing the mesh inside the track data. just have a position (+rotation & scale) for the tree listed in the track file and the tree just gets drawn from the shared object library. still gives the option for making special case trees that have their meshes defined in the track file. tire walls, chain link fences, crowds and other stuff *could* be done this way too, though with varying needs for parameters passed when declaring an instance in the track definition.
We could have a shared object library right now, if someone simply made the tracks know how to look in a different place for their objects, and set up the tracks' list.txt to include those objects. It really wouldn't be that hard...
zimluura Wrote:was thinking allot about how doing 3 lod models for 8 trees is allot of work, but doing them for all the trees in the nurburgring sounds completely insurmountable. and then ontop of that, in 3 years when videocards are 5 times as powerful it wouldn't be that bad to model a single higher level of detail for each tree. and then wham, every track has another level of pretty for its trees. but it's theoretical to me ie; could be that it'll take 20 indigenous and 20 deciduous to get things properly differentiated, and that's a tall work order.
We didn't have quite 8 trees but this is exactly what it did, LOD based on distance away from viewer. they also sorta faded in instead of just appearing out of nowhere so they were less jarring when you first see them drawn. You can download one of our older releases to see this in action. I just checked, and the release you want is 2005-11-03.
zimluura Wrote:dynamic sky: i saw some shots of it in the album, thought it looked really cool. was hoping it hadn't been totally abandoned. hadn't thought too much about modeling the distant hills in with the rest of the track stuff, but that does make perfect sense. only problem i can see is that micro vs. macro in the same 3d modeler scene has, in my experience, been sorta tricky. that said i haven't been using blender for very long, and most of my experience is from truespace.
Yep, it's still there...as far as I know. Have you checked that it works with the new scenegraph code, Joe?
joevenzon Wrote:In fact, I *think* that if you model the hills in blender but mark them as "skybox" they should look as if they are infinitely far off (they would move with the camera, just like a skybox).
That would be an interesting effect.
