incorrect lod for sub_models

[richardpl]

Currently we have models that use lod in static to generate mesh:

define_model('posl_green', {                                                                                                                                             
        info =  {                                                                                                                                                        
                lod_pixels = {2, 5, 10, 0},                                                                                                                              
                bounding_radius = 1,                                                                                                                                     
                materials = {'green'},                                                                                                                                   
        },                                                                                                                                                               
        static = function(lod)                                                                                                                                           
                if lod > 1 then                                                                                                                                          
                        use_material('green')                                                                                                                            
                        sphere_slice(3*lod, 1*lod, 0, 0.5*math.pi, Matrix.scale(v(0.1,0.1,0.1)))                                                                         
                end                                                                                                                                                      
        end, 

so code in static will be called only once and used always in other words if lod of model was 1 when it was first called generated mesh will be sphere slice of only 3 divs which does not look nice at closer lookup.

[Luomu]

No, this is perfectly correct use for the lod parameter.

This model:

define_model('spheretest', {
  info = {
    lod_pixels = {10, 20, 30, 40},
    bounding_radius = 1.5,
    materials = {'body'}
  },
  static = function(lod)
    set_material('body', .5,.5,.5,1, 0,0,0, 0, 0,0,0)
    use_material('body')
    sphere(lod)
  end
})

Will create four levels of detail for the sphere:

In the model you have pasted static lods 1-3 will be created. 4 is skipped as the pixel radius is 0. 1 ends up empty because of that lod > 1 part.

If you are seeing some lod problem it might be call_model related.

[richardpl]

Look at headlight pos_lights sub_model on hammer ship on pull request list, in modelviewer. Depending how far you are from ship and than changing first slider (gear) will give different result. Zooming in will not give you higher divs on static part of sub_model.

[Luomu]

It seems like yet another weird lod calculation bug.

Lights on the underside of the ship appear smooth at close up, but at the same range the ones at wingtips and headlights are noticeably rougher:

I added little text()s to the lights to see which lods where actually in use.

So possibly being farther from the model center affects the calculation...

[richardpl]

Parent model of sub_model should not affect sub_model lod switching in any way.

[richardpl]

Perhaps this have to do with relative camera pos calculation, does lod switch to 3 if you rotate ship around?

[gernot66]

it's what i'm constantly arguing about

don't search to far away it's offense,

the lod for sub-models didn't works proper, that is since a change to lod calculation almost a year ago... this is imo simply because you have to enter now the bounding radius of the final model to get a proper lod for a small object like a poslight.

but how can i? the sub-models are multiple used and you can't simply preassume a bounding radius, everything will be wrong from one or the other pov.

it was ok, before and personally i never understood that change fully, but accepted it as a must. before you had to enter the bounding radius for each model separate, "intra model" or "extra model". that has worked perfect it was only not to clear to some i guess what bounding radius had to be entered and a little more (guess) work.

but i was told it's a needed change so i accepted it, but never was satisfied with it, good that someone else to pointed that out (sometimes i guess i'm going nuts)

if that stays like a rock, i can rewrite the poslights as function (and the rest of lod sensitive sub-models) that could help, but needs a complete overhaul of all models then (which is unevadable anyway for my models, imo).

but of course i would gratefully accept any other solution.

apart from that, due to that change still some of my ships need a fixed up lod.

---

something that is a bit disapointing, why do have others to mark issues i pointed out long ago, to get heard?

well, i guess i know the reason (people in "protective clothing", uneducated workers i mean by that?) that's not uncommon to me.

some funny notes out of my life,

german students in the NPP asked me often "where did you studied" or "in what are you graduated" answer, "life?"

i was sitting in the train once, a older prof was teaching to two young students railroad cybernetics, it has awoken my interest, and soon i asked a question, his answer, "do you think you understand what we been talking about"

pure prejudice, i was sitting there in my dusty,oily overcoat, perhaps accompained by a beer. btw, i didn't asked further, but listened further (that's not forbidden).

oh, yes i understood what it's about, it's about using re-emerged energy from trains running downhill, mechanically or electrical. and how it can get used (storing isn't possible, except you would use it to pump some water uphill) at the time you have emerged it, simply said.

i know dusty, oily overcoats are no graduation :) (a real big smile)

[robn]

@gernot66, nobody ever thought that there wasn't a problem. Unfortunately you were never able to articulate the issue in a way that we could understand or test.

Fortunately since then @s20dan was able to come up with a test case. When first introduced, the Hammerhead model showed the pilots through the front window if you zoomed in. Since this lod break, the pilots no longer show. With this test case I was able to track the fault to commit @5fb87dd7.

I've not had time/inclination to look into what this change does, why it changes lod behaviour and what the correct fix should be. I'm happy for someone else to dig into it.

[richardpl]

From that commit it is obvious that camera pos calculation have changed for sub models. But thrusters really do not use call_model so there is no point to change that line.

[robn]

Possibly, but it might have affected things in later commits. Tom has a bad habit of changing things that aren't related to anything else in the commit and aren't mentioned in the commit message, sometimes with far-reaching ramifications.

If you want to revert that single line and do some testing, feel free - I'd be interested to know the results.

[Luomu]

The new model system is merged, closing all LMR issues