[Nuke]

currently subobjects inherit the lod of the parent ship, but is it possible to give each subobject a set of lod distances? it would allow for more detailed turrets without slowing down the game by loding them based on distance to them, rather than the parent hull object. lets say you had a colossus sized ship with about a hundred super detailed turrets. say your ship was within the detail distance for the ships first lod, however since the ship is big then turrets on the other side of the ship, several klicks away, will be rendered at detail 0. this doesnt make any sense. those turets should render at a lower lod.

[Aardwolf]

Isn't that basically what detail boxes do?

[Dragon]

Amaterasu works this way, that's exactly detail boxes.

[chief1983]

Yup, detail boxes.

[Dragon]

If you don't know about what we are talking, check here: http://www.hard-light.net/wiki/index.php/Detail_box
TSJ Amaterasu (example of usage of this feature): http://www.freespacemods.net/download.php?view.533
Texture update (fixes a handful of problems with Amaterasu, including missing texture): http://www.freespacemods.net/download.php?view.534

[Nuke]

youre all missing the point. the point is the current way lods for subobjects are handeled sucks. detail boxes really supports 1 or 2 lods. by allowing detail distances for each subobject, you can have more than 2 lods. transitions between lods would be smoother. you wont spend hours setting up hundreds of boxes. further more this can be used with older and existing models just by adding one line for each subobject in the table, rather than editing hundreds of objects in pcs2. you could easily cull hundreds if not thousands of unnecessary polygons from the scene. detail boxes were, cute, however i dont think the idea was thought out very well.

[KeldorKatarn]

I agree. The detail boxes are a bit awkward

[chief1983]

I wish the data were in a table and not the model file, model data seems like a bad idea in general to me.  Expanding detail boxes to allow more than just a min and max would be nice though.  But you still have to set up every one of them independently so it's not much faster or anything.

[Nuke]

placing the detail box in the table sorta helps, but still you would be stuck with just 2 lods. expanding it to allow more. possibly having 2 detail boxes per object, one positive and one negative would improve the system. doing the same thing with detail spheres could also work. but its still a lot of setup. you could simplify the math involved by instead of using 2 vectors each, place the box around the geometric center of the sub object, with a width, length and height specification (or radius in case of sphere). at parse this would be converted into two vectors, so internally the system would remain the same. the modder would only need to enter 3 numbers for each box.  this i could probably live with.

but i still think that if its possible my original idea should be used regardless of whats done with detail boxes. it would allow better loding with a lot less setup, freeing up a modders time for there tasks (like debugging their mods ).

[Aardwolf]

Part of the reason for the way it works now is so that you can do things like long tube-shaped detailed areas (e.g. fighterbays) without having them be fully detailed anywhere other than inside and past the ends.

[Nuke]

im not saying they dont have their uses. im just saying their not good for detailing common subobjects. for something thats inside the ship where the detail box protrudes some area, then that is the perfect use for a detail box. they are not useful for using on every subobject on a colossus sized ship.

[Nuke]

since this didnt go anywhere, and its still something i think the engine seriously needs. what would be the best way to implement such a feature, and is it even possible without a major overhaul?

[Aardwolf]

Why not do an all-out BSP/Octree/some other tree-based system to do dynamic LOD'ing? It would of course require precalculated data, which might possibly be generated much like the stuff that always ends up in /cache

It would be a bit of a hefty job to implements, but ... any thoughts?