Racer v0.8.36 released

[Ruud]

A good date for an update. ;-)

Racer v0.8.36 is at http://www.mediafire.com/?i6rnbmthb5sr3dh (52Mb)

I'm going to investigate the cameras; the location wasn't right when we modified them relative to the nullpoint, but I seem to have some trouble getting them right in the Lambo. I'm away for a week first though...

The changes:
- Bugfix: script parentheses could cause confusion: 'paint sin($a*0.8)+10 at float[2]{ 50,50 };'
would give numbers between -1..1 instead of 9..11 (priority conflict).
- Bugfix: the camera locations not relative to the nullpoint. This does mean
you should move your camera positions!
- Added 'terminal' console command; this opens an output window. Also added dev.terminal in racer.ini to open it at startup.
See also http://www.racer.nl/tutorial/development.htm . Useful for content development as well; seeing warnings quickly.
- Entering of console commands is now also possible in the menu screen (although not many commands work here).
- Added 'debug <path>' to show a subtree's values live, much like the Ctrl-1 to 9 screens.
- data/cars/default/car.ini contained a differential tree which was not used; now split into 'differential' and 'differentials' (the latter is preferred)
- FMOD upgraded to v4.36.5 (fmodex.dll)
- Added 'reload globalviews' console command to reload data/gui/globalviews.ini
- Added damage parameters to default/car.ini (damage is still very alpha functionality)
- Added views.ini type 'clip' (for example for a filling bar) - currently it stretches the image though
- If a car's view0 was empty, Ctrl-9's second subpage could crash
- Added 'get focus car' script command to retrieve the car in focus (unlike 'get local car' for example)
- 'doc scriptfuncs' now opens the file after creation.
- Pacejka player could not edit 'a0' in Pac96 mode.
- Pressing Ctrl-0 twice would crash
- racer.ini's collision.report_car_track_collision now shows collisions between objects in the console
- DOF_Fix had an endless OpenGL error loop
- Endless roads possible by defining endless.min.x/y/z and endless.max.x/y/z in a track's special.ini
See http://www.racer.nl/tutorial/endless_track.htm
- Newton upgraded to v2.34 (newton.dll)
- Movables initial state is now no longer to freeze; this to fix framerate issues (although it's a little slow at the first few frames).
- Added generic model align_axis property, to fix one of the axes of a generic model (to prevent rotations; only 2 endpoints are defined).
This was done for Boomer's IMP car, to keep a suspension model from rotating when moving.
- Added susp<n>.susp_y_change_per_rad (around 0.01 to 0.1) to dynamically move the suspension attachment point for geometric effects.
- Ini.exe would crash when adding a non-existing key
- Added 'show lidar' and 'hide lidar'. High-end laser scanned tracks only (alpha development).
- Added 'lidar movex <v>' plus movey and movez commands to translate Lidar data to match the track.
- Gearwhine sample now also uses jitter (similar to the engine).

Enjoy!

 

[KS95]

+2.

 

[Mr Whippy]

& what about the LIDAR commands ?

I'm quite interested, since the data is available via IR satellite imagery & can be baked quickly in 3D polies. Our photonics technologies enables us to see thru everything & we can use this data for building real existing worldwide tracks without NO EFFORT.

I believe the LiDAR features are for when Cruden use a super high density surface mesh direct from LiDAR data, but it is stored simply as a look up table for the physics, and doesn't even go near the graphics pipeline. I guess this is for their users who want super high quality surfaces to drive on that exactly match the real thing...

In practice satellite LiDAR capture would be like driving on 1m boulders due to accuracy issues.

Even aerial captured LiDAR (helicopter) is rather low resolution, offering only maybe 10 points across a tracks width, with several centimetres vertical error per polled point.

LiDAR is only really useful for track driving surfaces when it's done like iRacing do it, ground station scanning at various locations on track.

For the wider area LiDAR from aerial/satellite may be useful, but it's gonna cost lots. It's easier for us to come by contour maps and satellite images to make our terrains by eye... which for the most part are perfectly good enough


Dave

 

[QuadCoreMax]

You know Dave, I love using new technologies, so I'm excited to use that kind of data in my future projects (large maps). For now, I got a crash after executing LIDAR command in console. Some of the "filtered" cloud points data could be used for instantiating objects (xtrees...) which would load dynamically & would scatter randomly on these cloud points...

Need to say, I'm really happy, this version seems working fine with skeletons/bones animations, the terminal window, the system feature, the new scripts functions & the new 3ds Max Racer Export plugin.

Amazing job Ruud/Mitch !

Bug:
At high velocities, when a car crashes against an Xtree, the sound of all cars (race) might disappear...

 

[Mr Whippy]

The 3DS Max Racer Export plugin is great. It does need some more toggles though really, so you can fine tune how it works for you a bit more. I'm sure such additions will come with time

I need to look more into the system feature (car.ini variables adjusted on fly during play via scripts!?), and the skeletons/bones for driver hand animations...

Currently looking mainly at tracks and shader/geom optimisations to get FPS up!

Dave

 

[QuadCoreMax]

yeah exactly, this version enables us to tweak car.ini variables on fly !

 

[Ian Strom]

On the topic of damage,(yes I know I am late) we need it like Street Legal Racing: Redline has it!

 

[Pedro_Takumi]

On the topic of damage,(yes I know I am late) we need it like Street Legal Racing: Redline has it!

looks like we all play the same games but isnt that a heavy system for the hardware? street legal is one of the best games made just for its "assembly system" but in terms of performance doesn't use the resources very well :oops: at least its my experience with it, ran it in 3 pcs for the last couple of years

 

[QuadCoreMax]

IDK about Street Legal Racing (I think there's no G25 support), but using skeletons/bones cars + scripts (rcarmodels) & you're ready to simulate something like SLR or RoR damage system...

As you might know, doing skeletons cars requires a "closed" mesh modeling in order to make it work...so yeah takes a lot more time to model such an idea !

Mitch showed us an example recently, unfortunately I can't find it anymore...there was some tweaks in the body section of the car.ini file. Anyone ?

 

[Ian Strom]

I use my G25 with SLRR. >_>

 

[Mr Whippy]

Hmmm.

Ruud, is there any chance we can move to the movables system described a year or so back.

Ie, geometry.ini is always loaded, and then if any movables001...999 files are present in the root directory of a track, those objects are appended at load time?

That way it makes it really easy to swap out different movables layouts really quickly.

Alternatively I suppose track skins would work too, but I have yet to see how they would actually work.

My primary issue is simply having ALL objects in one file. It's slow and cumbersome to manage currently.




Secondly, I have been messing a lot with rendering speed. Ideally having items bunched into one geob is better for render speed. I can have over 5000 trees each with a 512x512 texture (16 varieties of tree on one 2048x2048 atlas) on my airfield test track at a cost of about 10fps. The trees are all one dof and one texture.
The track loads with 125fps, and about 45 openGL render calls.

When I add my cones to the track, the FPS is around 90fps, and I am now at about 125 openGL render calls, probably about 60 extra calls for the cones in view at the start.

If I now add an LOD distance of 200m to the cones, the FPS speed is much improved again, and the draw calls reduce. However, if I reduce my FOV and bring the cones into view again, you can clearly see the draw count go up and the FPS drop significantly.


It just seems expensive to have lots of movables simply because right now they are drawn by the GFX pipeline one at a time. Is it possible to somehow draw all the cones that share the same shader in one draw call?


Obviously it's not a big problem per se, but it would be cool to have a work around.


On movables generally though, this new version seems much better for FPS. It seems only the ogl shader call count is costing us now.



Lastly, were all car reference points (cameras, exhaust backfires etc) wrong since the CofG movement fixes we had a few versions ago?
I was fairly certain that coords for a camera from 3DS Max worked almost perfectly when transferred to Racer... but perhaps not. Should exact XYZ coords from 3DS Max match perfectly in Racer now?


Cheers

Dave

 

[DavidI]

Interesting, so where we used to create large numbers of objects/dofs so Racer could cull them, you're now saying that its better to have small amounts of objects/dofs, and let OpenGL/GPU cull them instead of Racer?

 

[Mr Whippy]

It would seem that way yes.

FPS seem directly proportional to openGL calls, and they seem proportional to the shader + dof count. So one shader on one dof is one call, irrespective of complexity.
Ergo, 5000 x-trees (20,000 triangles) in one DOF, with one large texture shader (atlas of 4x4 512x512 trees (1x 2048 x 2048 texture)), is very very fast to render.
Even though it is in essence one DOF with 10,000 quads inside it (or 10,000 geobs), it runs really quickly.

The same is true for cars. Trying to get a car down to a few key shaders, say reflective, matte and glossy, and glass/transparrent, and you have 4 shaders. A 50,000 polygon 4 shader car almost doesn't even impact FPS! Add 10 of them and the FPS are within about 10% of the original FPS (in my quick tests)


Of course, the issue then is overall scene polygon count, which will impact FPS. I believe the GPU still has to process un-seen/filled polygons in it's polygon pipeline to be able to cull them, so off-scene polygons will cost you ultimately when your scene gets very full.

I'd imagine there is some prudence in chopping trees like this into blocks. So maybe one for each primary direction from the track centre, so North, East, South and West for example, say 10,000 triangles each. It's unlikely you will ever see more than two of these blocks at any time, but it means perhaps 20,000 triangles don't even need to be in the GPU memory to be processed to determine they are not even visible anyway.
That is then 20,000 triangles you can use in grass planes at the sides of the track that LOD out after 150m, using another shader.

Total passes from trees in one DOF > many DOF and some grass goes from maybe 1 pass to 3 passes, but you gain in having the grass there, or some other details.


I guess right now we are suffering from openGL call saturation causing our generally low Racer fps. There will be a point where geometry levels hurt us, and splitting DOF's will become a more important part of the balance vs the openGL call count.

My recent testing has led me to be a lot happier to use loads of polygons though, and ideally less shaders and more info in textures. Ie, try getting a car in under 10 shaders. With lots of cars on track the days of having a 50 shader car will be over if you want nice FPS!


When I get the time I'll try do some definitive test track or something, and show the results of different ways of doing the same thing, but the FPS impacts of the different methods!

Dave

 

[Mr Whippy]

Interesting bit here on Unity 3D engine:

http://unity3d.com/support/documentation/Manual/iphone-DrawCall-Batching.html

They batch after visibility test. Thus they can split objects up into more DOF to allow the least amount of polygon/geometry data to be managed at any time, then it is batched together (per shader I assume), so that it is done in one pass.


So in my cones example, Unity would see 150 cone dofs with the same shader, and effectively turn it into one pass at the renderer shading stage (though the cost of doing the batching on potentially moving items could be costly, but probably not more than a render call for EACH cone)


I wonder if this is a common feature of modern renderers or not? It'd certainly seem to be the best way forward, since my methods above are ultimately a compromise one way or the other.
I guess it's still good to have less DOF than more when they will all be seen at the same time anyway, but having too DOFs few might mean lots of wasted polygons that don't get rendered are processed/culled each frame.
Ultimately doing atlases or batching by hand is possible, and probably can be done very well, but it is time consuming. Certainly something I will be doing on my work, but it certainly might be an iterative process finding the right balances of batch chunks to geometry culling cost!

I guess the method employed by Unity 3D engine has a cost, but it's probably no more costly than having more openGL calls than necessary due to inefficient batching to start with!


Hmmmm


Dave

 

[QuadCoreMax]

The movables cones are defined in Tracked via 1 dof only...

Bug :
When you 'show splines' + press 'CTRL + v' the screen goes black.
In scripts functions, I think it's not 'warp' but 'wrap'

 

[Mr Whippy]

The movables cones are defined in Tracked via 1 dof only...

The horrible default cones that get instanced are defined with one dof. I would guess that they each take a render call though.

There is no way to add your own new instance'able objects either, I'm not sure where the default shader resides. It'd be good to have more default cones and other objects, but we need a shader/texture folder alongside them so we can add new ones easily


I've built my own set of cones/textures/shaders. They work nicely (apart from trackEd destroying nested properties, argh, another reason why I avoid trackEd like the plague!), just technically they are a bit slow due to not being batched. Since they are small, LOD'ing gets around the problem fairly well

 

[QuadCoreMax]

Show your example...I'm interested !

Found another bug, in Tracked Traffic, the 'remove selected waypoint' function when executed only edits the graphical part in Tracked not in the traffic.ini file.

Anyways, good stuff there with scripting, just managed to generate a new traffic.ini file when ingame driving only for reuse in custom routes/waypoints...instead of doing it manually via Tracked Traffic tab.

 

[radome]

Interesting bit here on Unity 3D engine:

Just wondering: Is there a story, or any significance behind the similarity between the Cruden and Unity logos?

 

[DavidI]

It would seem that way yes.

FPS seem directly proportional to openGL calls, and they seem proportional to the shader + dof count. So one shader on one dof is one call, irrespective of complexity.
Ergo, 5000 x-trees (20,000 triangles) in one DOF, with one large texture shader (atlas of 4x4 512x512 trees (1x 2048 x 2048 texture)), is very very fast to render.
Even though it is in essence one DOF with 10,000 quads inside it (or 10,000 geobs), it runs really quickly.

The only way I've found so far to animate trees is to have them as seperate dof's so each objects's centre position is known. This then creates a problem for me.
Maybe Ruud could comment on the future, is this likely to change, do I have to drop my tree animation & group my trees into dof's?
Mixing animated & non animated can look ok, but only with even amounts or more of animated versus static, so I still end up with a reasonable amount of dof's. I can glob all my tree trunks together into a few dof's, as I don't animate them.

 

[QuadCoreMax]

To avoid manual positioning for each animated object via Tracked, the same principle as I showed before could work, greatly reducing developing time, so setting 100 dofs could happen in matter of seconds just driving around....

 

[DavidI]

QCM, the trees aren't moveables, they are plain old dofs, but the shader the foliage material uses introduces movement that references the centre of the object to function.