• Welcome to PiBoSo Official Forum. Please login or sign up.
 

disappearing LODs on bike parts

Started by giopanda, June 29, 2020, 08:23:20 AM

Previous topic - Next topic

giopanda

hey guys!
straight from mxbikes since over there no one ever did LODs for bikes and i'm having some problems that they can't help me with.

basically i have the model, animated parts and LODs in game just fine, everything is working smoothly except for only one of the moving parts, the front brake cable.
it just disappear when i'm very close (therfore it's invisible in 2 of the onboard cameras).
the rear shock works fine, the throttle and clutch cables that bend when steering works fine, also the front brake cable works perfectly, it just disappears when very close with the camera.
the .hrc files are all correct, i tried converting to .edf with 3 different versions of fbx2edf with the same results..
so there's nothing else i can do without help or a good hint :D

thanks


h106frp

I have played a bit with animation but not LODded, however from my experiments;

Try calling the same LOD for all distances in HRC to confirm if its a single LOD issue or a camera problem

Check your object origins have remained intact during LOD layer creation - are all the LODS in a single .edf or do you have one for each LOD - mainly thinking about the possible impact on object/mesh naming 

Check your vertex order has not become corrupted during LOD creation - did you re-build the animations each time?

giopanda

thanks!
i forgot to add that the animated parts are not in the LOD but just in the main model..as Piboso told me once he never even tried adding animated parts to lods so the results might be unpredictable, and i can confirm because the one time i tried basically all the vertex of the lod were placed randomly and the bike looked like it was blown up.

i followed the stock bike setup, so i have model.edf with animated parts, then i have model_lod2.edf without animated parts.
in this one i removed all the small bits (included the animated cables) and left a static rear shock parented to the chassis (removing this would have left a big empty space inside the frame)

h106frp

I guess your animated LOD experiment confirms that the vertex order must be consisitent between LODS for animated parts - the 'explosion' will be due to the vertex id number changing. I suspect if you did not alter the animated parts models at all between LODs it may work.
It may also mean you have to be a bit careful with object or mesh names to avoid conflicts with the base LOD animations.

giopanda

i don't think i understand your last post..
as i said to avoid problem with vertex changes i just used the same mesh (saved under a different file name) and removed the animated parts from it (and added the static rear shock from the original model, which never went through the animation process)
what disorients me is that everything went through the same exact process (again to avoid vertex problems) for animation and is perfect, except for that  :o

h106frp

June 29, 2020, 10:02:40 AM #5 Last Edit: June 29, 2020, 10:04:46 AM by h106frp
Sorry, probably just thinking out loud  :)

If you try using your LOD layer as the same model for all distances it should be a bit more obvious what is occuring, as it has no animated parts its just the usual suspects of object parenting and textures.
 As I understand it, at the 'switch' distance the entire .edf is changed over so as long as you change both fsusp and steer and at the same distance it should be OK - if you only changed one of these at a time I can see where it might get complicated with the animated part

giopanda

ok makes sense now, but not the whole model gets replace at once, the parts get called from a different model (model_lod2) and as Piboso told me the distance at which the .hrc calls the next LOD is not the same, as it is not in meters.
it changes proportionally to the parts size, so if you set all the distances at 10, the smaller parts get swapped at closer distance.
i'm sure it has to do with the _lod2 model that doesn't have that cable, but i don't get why it only happens with that and not with all the other cables.
i'll do some more testing and i'll let you know, thanks again!

Hawk

Is it really worth being concerned about the LOD's until Piboso has a z-sort-culling routine implemented into his GE?

giopanda

Quote from: Hawk on June 29, 2020, 09:53:04 PMIs it really worth being concerned about the LOD's until Piboso has a z-sort-culling routine implemented into his GE?
:o  ???  :o

Hawk

Quote from: giopanda on June 30, 2020, 06:46:53 AM
Quote from: Hawk on June 29, 2020, 09:53:04 PMIs it really worth being concerned about the LOD's until Piboso has a z-sort-culling routine implemented into his GE?
:o  ???  :o

I take it from your reaction, that you didn't realise?

giopanda

Quote from: Hawk on June 30, 2020, 12:23:35 PM
Quote from: giopanda on June 30, 2020, 06:46:53 AM
Quote from: Hawk on June 29, 2020, 09:53:04 PMIs it really worth being concerned about the LOD's until Piboso has a z-sort-culling routine implemented into his GE?
:o  ???  :o

I take it from your reaction, that you didn't realise?

yep, no idea what you're talking about :D