Racer v0.8.34 released

[Ruud]

Racer v0.8.34 is out! Get it at http://www.racer.nl/download/racer0.8.34.7z (48Mb, note the 7z extension; you'll need 7-zip from http://www.7-zip.org ).

Enjoy!
Ruud

Changes:
- Bugfix: Director cam didn't work
- Bugfix: Rain didn't affect grip (snow did)
- ENet upgraded to v1.3.3 (small change to avoid unreliable packet regression, and disconnect fix)
- Added input limiters for Pacejka curves for slipangle/ratio/camber/load (see data/cars/default/car.ini)
(wheel<n>.pacejka.slipangle_min/max etc); see http://www.racer.nl/reference/pacejka.htm#inputsoutputs
- Bugfix: Replay was never painted; no camera was defined.
- Bugfix: particles in replays were not animated in reverse mode. Now they are (although not entirely correct)
- Turning AI on while offroad would cause a crash.
- Added ai.spring_factor in car.ini to add some magic forces to keep the car on track (use 'ai scale' for example
to add some speed to the AI line; check out 'ai save' and such).
- CurvEd import of ASCII txt and CSV added.
- CurvEd imports were buggy (zero) if more than 50 points were imported.
- Added textures.stub in racer.ini to optionally load a single texture for every loaded shader; useful
when testing mipmapping (if you're using mipmaps effectively, see http://www.racer.nl/tutorial/stub_textures.htm)
- Added data/images/texture_stub.dds as a default images for the feature above
- Added dev.fast_fade in racer.ini to allow quick fades while developing
- Added wheel roadnoise filtering to simulate rubber; see http://www.racer.nl/reference/wheels.htm
- Added ai.rc_factor in car.ini to be able to help AI if you give it a high grip_factor as well. See http://www.racer.nl/reference/carphys.htm#ai
- Added ai.cg_factor in car.ini to lower effective CG height to help AI drive faster through turns without flipping.
See also http://www.racer.nl/reference/carphys.htm#ai
- susp_implicit_integration now set to 0 for explicit physics. It seems stable for F1 cars with tire_damping,
and the implicit method creates buggy load values in the tires.
- Added ghost.update_if_loaded (defaults to true) to determine whether to update the ghost lap (if you're faster),
even if you've explicitly loaded one with ghost.load.
- Materials without names in DOF files used to get the exact texture name (ie 'body.tga'). The extension is now cut, so it'd become 'body').

 

[Mr Whippy]

DDS are ok.

I think for most content you may as well work in TGA, and just get someone to do a TGA > DDS batch conversion for you, and find/replace in the shader file, come deployment.

They are a pain to use in development just through being slow to load, slow to save etc... TGA can be edited, saved and reloaded over twice as fast to review in-sim changes. When doing recursive tweaks/improvements to shaders, those time savings can add up to hours of just annoying dead time in my experience.

Dave

 

[Alexander Knoll]

Bob, i tried some thing too...i started with a car body texture from (original) 2048x2048 and reduced it to at least 256x256 ^^....but the fps was the same...ok the car looks horrible :fwd:...so i don't know what it realy does...but i'm sure Ruud knows what it do^^

ok...one question: it doesn't matter witch resolution i use...this STUB Texture thing was always at the same "layer"(?? not sure if its the right word...)....or does it not affect this?

 

[KS95]

Chances are it'd probably make more of a difference to someone like me with a 512mb GPU. My system is pretty decent I just need another 2Gb of ram and a better graphics card (currently got the GT210 and a 8500GT on this one)

 

[Alexander Knoll]

Scott do you have some differ fps?
I've a GTS250 with 1GB....and feel nothing differ.......

EDIT:
...hmm....i try my server...he uses a GTS8600, with 512MB...

 

[boomer541]

Sometimes I look but don't see! Finally broke down and installed GIMP with the
.dds plugin and lo and behold all is clear.

A .dds image contains several layers where .tga images contain one or two layers. The texture_stub.dds image in v.
0.0834 has 12 layers if I remember correctly. The main layer is red wirh a big 1 in the center. the other layers are for the other colors, yellow, green, etc., that appear when using it with stub= in racer. ini.

Actually using a .dds on a car or track is a bit unclear to me as to how the extra layers are
implemented. Are they done wih the shader or just whats the process of using them.

It looks to me as the tool to use is the GIMP to make and save .dds images. I have to work on that but can see some great advantages now.

 

[Mr Whippy]

I don't think a DDS can have beyond 4 layers, just like an RGBA TGA file.

The 'layers' you are actually seeing in editing programs are the mip-maps, which are scaled down versions that are used when the object is further away. You *can* edit these if you want, and it is advised to do so for some items, but generally the re-sampling the editing program does from the original full size image is good enough (read up on it if you think you need to know more, mainly you could take extra care when mipping height maps to normal maps, and not mipping normal maps directly!)



The stub file everyone is talking about is just a visual representation of the mip-scale being used. The mip-levels have different images, so it's really obvious what mip-level would be used on an object in scene. If you see lots of 1's around, then that means the stub image is being used at full resolution, and it's worth using a big texture for that item.
If you see your wheels and tyres (looking at the Tatra here ) are running numbers like 4 or 5 on them unless you zoom RIGHT in so the wheel fills the screen, then it's a good bet that for almost all users you are just wasting texture memory by having the mip-level 0 (full size), that no one ever sees!


Dave

 

[camsinny]

Mipmaps.
Using the on screen keyboard so can't go into detail, but this should help.

 

[camsinny]

AAAH! Dave you ass

 

[Mr Whippy]

Hehe

 

[boomer541]

When I opened the texture_stub.dds image using gimp it had 12 layers and yes there are mip-maps.

 

[Ruud]

Ruud , why racer don't use all the cores of my core quad ? This is the fourth time that I asked lol.

Thanks , Buthmann

Racer uses mostly single threading; with async=1 you can run physics in a separate thread. However, this was really made for heavier modules (Simulink models compiled with Real-time Workshop for example). So basically, most of Racer stays on a single core, that's why you see only the one core being used.
Perhaps things will improve a bit with Newton using multiple cores, but for now, most of the times, graphics is the bottleneck (I mostly see around 10% physics and 90% graphics in use).

 

[boomer541]

I added a .dds converter to the download link. Can't remember just where I downloaded it from but I can't use the one that was posted as being from nVidia. This one is quite good as there are a lot of things to set up when saving. It does nice mip-maps.

http://www.racedepartment.com/downl...s-74/paint-shop-pro-dds-image-converter-5290/

Allows the creation, viewing and saving of .dds images in DXT 1-5 format.

Would realy like to see a tree .dds image that Mr Whippy has used and the shader code to view it.
Need to know just how to use a .dds image, thanks dave.

 

[DavidI]

Boomer dds & tga are interchangable in the shader. i.e. if you had a road material & converted road.tga to road.dds, you would just change
map=road.tga
to
map=road.dds
The difference is that the .tga has to be mipmapped by the GPU, the dds is already mipmapped. Though, as the mipmamming of the tga is done at loading, it only affects the loading time of track/cars, not fps. The way I see it, tga's are fine if the mipmapping done by the GPU looks ok. When it doesn't dds format is good because you can manipulate the mipmaps to make them appear as you want (mostly)

 

[Mr Whippy]

DDS are core to good normal maps, because mipping normal map information is biasing the data as it was at full resolution, and it becomes less representative of the normals you would see at scaled down levels.
What DDS lets you do is generate the normal map from a height map at different resolutions, and so each mip of the normal map is giving you a good quality representation of the normals. Nvidia DDS plugin for Photoshop can do this automatically.

There is a great paper on Nvidia's web docs about the issue.


But generally, best to just author in TGA. Do everything you need to. Once you are ready to deploy to the masses, then just get someone to batch convert the lot to DDS, then do find/replace .tga > .dds... easy.

If you are worried about the normal map issue, just keep the original height maps for all the normal maps, and batch process those appropriately too.


It's probably a 15min process and it is worth doing. But as said earlier, best to author in TGA, get everything right, then just do this as a 'final touch' process to get everything optimised for FPS etc

Dave

 

[camsinny]

How come I keep getting these annoying messages when I make a new track about there being no collide meshes.
"None of the track's nodes in geometry.ini have the SURFACE flag; nothing to collide; cars get stuck in Newton!
Remedy: set surface flag (4) in geometry.ini, delete the track's cache directory and try again."

Except it doesn't work. And isn't the collide flag 6 anyway?
Happens in .34 and .33
Super hard to make a track when you can't run it.

 

[boomer541]

Thanks for the replies, DavidI and Mr whippy. I will try a .dds image on a track/car to see the effect.

 

[Mr Whippy]

How come I keep getting these annoying messages when I make a new track about there being no collide meshes.
"None of the track's nodes in geometry.ini have the SURFACE flag; nothing to collide; cars get stuck in Newton!
Remedy: set surface flag (4) in geometry.ini, delete the track's cache directory and try again."

Except it doesn't work. And isn't the collide flag 6 anyway?
Happens in .34 and .33
Super hard to make a track when you can't run it.

Hmmm, I'm using .33 here iirc, and flags=6 is working fine.

Are you using trackEd to set flags?

TrackEd is evil... in .33 it resets (deletes) all my lod0_z settings. So I have to backup geometry.ini, edit the track cameras/start positions etc in TrackEd, save it, then revert to my other geometry.ini again... arrrgggghhhhh!


Dave

 

[boomer541]

Camsinny,
Vertices don't appear until .dofs are saved and in geometry.ini.

I loaded in tracked, a track that had a track.ini file and then loaded the track.dof files. No vertices. Saved the track and closed tracked. Opened geometry.ini and set all flags from 0 to 6. Opened tracked and loaded track. got vertices then splined and set the rest of the items required and ran the track. Worked ok. The flags need to be set to collision or not in geometry.ini.

Hope this helps

 

[camsinny]

Setting it in geometry.ini.
Tried before and after clearing the cache directory. Doesn't work in .33 or .34 however it does in .32
Might have to wait til this coming weekend to test again. I'll try to get a process on how to replicate it.

 

[boomer541]

I tried all tracked's back to 0.0820 and all didn't show the vertices until I saved the track. Then reloaded it after setting flags=6 in geometry. Worked ok but not like tracked used to work back about ver 0.05b something or other. It definately needs some work.

Got no Qlog errors when trying the track.