i'm not really sure when this happened but the sky and the horizon don't get drawn anymore at a large ddistance but instead they get rendered at the original size which breaks quite a few of the tracks. le mans is a good example, just drive a little bit and you'll find yourself outside the sky dome.
Thanks Alex, I'll look into it as soon as possible.
looks like the sky dome/horizon rendering broke again. this time i think it is the vertical offset. just go to Ring2007 and you'll see the horizon way up in the sky.
(02-17-2014, 05:01 PM)NaN Wrote: [ -> ]Will do, thanks again.
thanks for fixing it, but i don't understand the commit comment:
TRACK: Add workaround for tracking skyboxes geometry vertical offset (should really be fixed in track data).
what needs to be fixed and how?
--alex--
No need to fix anything atm, just a reminder for me, when we eventually switch from joe/jpk to a more capable mesh file format, to adjust skybox geometry so that this workaround can be removed.
In detail:
The old renderer had extra code to center meshes relative to the camera (vertical tracking case) when drawn. The new code ported from gl3 renderer avoids this, but requires the (vertical) center of the mesh to be at origin (z=0). The workaround is doing this when loading the track. It would be cleaner to adjust it in the data though.
(03-01-2014, 04:32 PM)NaN Wrote: [ -> ]The old renderer had extra code to center meshes relative to the camera (vertical tracking case) when drawn. The new code ported from gl3 renderer avoids this, but requires the (vertical) center of the mesh to be at origin (z=0). The workaround is doing this when loading the track. It would be cleaner to adjust it in the data though.
this is what i was afraid of. if you search through the archives you'll find out the posts where i requested this feature and the reasons why i requested it and the discussion joe and i had. in short, these are tracks imported from other formats and the origin is all over the place (i don't think any are centered at zero, but i could be wrong). aren't you the guy who suggested we should get rid of the bump coeffcients because bumps should be implemented in the mesh? :-( whatever...
--alex--
The adjustment is trivial, can/should be automated. What are you afraid of?