Racer v0.8.37 released

Ruud

RACER Developer
Just in time for X-mas. ;)

Get the new version at http://www.mediafire.com/?hc44aiq5izp4iqi
Then get the racer.exe/pdb which fixes reflections at www.racer.nl/temp/racer0838_alpha.7z

At some point we're going to have to call it v0.9rc1, since this one does a little tweaking to the graphics intensities (energy conserving) and sets cast_shadow to 0 by default. Most shadows will disappear; a huge fps boost until you put shadows back in shader files (.shd).

Merry Christmas!
Ruud

The changelist for v0.8.37:
- Added views.ini keep_aspect property to maintain aspect ratio for static images. See http://www.racer.nl/tutorial/dials.htm
- dyn_standard_reflect_window_f.cg now uses alpha as reflectiveness as well; opaque parts get less reflection
- TrackEd's AutoAseToDof has improved error messages on bad submaterial usage.
- TrackEd: some (progress) dialogs never appeared. Copy flags to group didn't work.
- TrackEd now colorizes the Collide and Surface flags in Props mode (F4) for easy tweaking of flags.
- standard_bump_detail_f.cg had a hardcoded 12x scale; now it uses the scale defined in the .shd file
- The garage track is not shown in the 'Select Track' screen anymore.
- Added log.events.host/port settings for remote racer tracking (niche usage).
- Lidar data (track.rld files) can now be sorted and driven on. Pro use only.
- Added car pitch/roll in body AND world coordinates in the Ctrl-9 debug screen.
- Added 'analyse shaders' command to check all shaders (track.shd/car.shd).
- The shaders default 'reflect' value for each layer is now 0 (was 1).
- Final tweaks in the shading system; energy conservation for diffuse and specular. For diffuse colors, this
means diffuse colors are divided by PI (assuming diffuse colors are kept between 0 and 1), and specular
colors are being corrected with (n+6)/8*PI.
See also http://www.rorydriscoll.com/2009/01/25/energy-conservation-in-games/
- Timers are now in microsecond accuracy using QueryPerformanceTimer(). Multicore machine issues?
- Profiling is more accurate due to the better timer accuracy. More graphics divisions added.
- Shader cast_shadow property by default is now 0; it's better to explicitly define shadow-casting materials
since you don't need a lot of shaders to cast shadows to still get a good image.
You *will* need to add cast_shadow=1 lines for shaders that you want to cast shadows.
- Depth texture setup optimized for shadowmapping; quite a big fps increase.
- Added look/left right controls (look_left, look_right) to dynamically look left or right (Q/W by default)
- In your controller file you can add global.left_right_look_velocity to set left/right look velocity (default=250)
- In your controller file you can add global.left_right_look_max to set the max left/right look angle (default=45)
 
Maybe the disco cams could be handled in special ini, idk would be great to decide which array of custom effects + how much randomness we want to occur when triggered ? !

We could have disco cams which randomly & dynamically find new placements based on our splines/waypoints, so that none of our replays or AI playing would happened in the same manner...I think I already suggested this idea back some versions ago.

Since we debugging so much, wouldn't be bad to introduce new camera debugs for TC & TKC,..

I was also thinking of instantiating simple TCs via scripting to randomly search & find a new dynamic placement, but I think Racer isn't listening to the update/change of its own files, AFAIK.

======================
Bug ?

When tweaking a TC position in Tracked & re-saving the track, all other cam values are reset to default values....hmm little revision of Tracked is needed...same story with mass & stuff from the movables.
 
This thread is kinda proving the track cams are not ideal right now :)

I have no idea what the keyframe entry or flags entries do, I just use trackEd and go with it.

All I know is the keyframe cameras are no use as long as they cannot be mixed with the non-keyframe cameras.


What would be a nice feature for track cams is if the in/near/out boxes also had radius values which could be used to pickup a car by a new camera even if the car is still outside the main radius of the camera, since others have noted, setting camera radius is pretty much fixed to all cameras needing a similar radius amount for them to work nicely.
For instance, there is no way to have a single camera hang on to the car for a long time as it drives away down a long straight, without that same camera picking the car up a long way away from the other side too. The only way to avoid that is to have lots of smaller radius cameras up to that point.

Keyframe cameras get around that, but then they are horrible to author on anything like an airfield type track, or multi-path tracks or anything that isn't a race circuit basically. They are also really hard work to put in place in TrackEd!

I'd certainly say track cameras for v0.9 need outlining clearly so authors know what they can and cannot do. Right now we have three possible ways forward. Dump keyframe and work with the old ones despite them being limited. Make them work together. Or finally, move to keyframe cameras but add functionality to cover the old features too.


Hmmmm

Dave
 
Bug ?

When tweaking a TC position in Tracked & re-saving the track, all other cam values are reset to default values....hmm little revision of Tracked is needed...same story with mass & stuff from the movables.

It destroys nested values too it seems, so for example, setting a few cone variables at the head of geometry.ini file, say big cone and small cone with appropriate mass and inertia, then having cone123~big_cone or small_cone, upon re-save in trackEd, all the values are copied hundreds of times to all your movable cones.

It's that destructive nature of trackEd that makes it not very nice for us, and it appears it does it with other things too as per your post :(

trackEd really needs to start being sensitive to information it loads in, and retaining it, rather than just ignoring it and re-writing defaults or collapsing nesting.
Worse still when it changes things you don't even touch. Ie, you adjust one camera radius and it re-writes all your geometry.ini file too!

Madness.

Dave
 
Also, the disco cam automatic 'around the car' camera animation/interpolation, you definitely see that those keyframes need to be placed far away from each other in your Racer code timeline...Interpolation points over short time laps or space/distance, is messy ! It's like NURBS technology, try duplicating a bunch of non equidistant curves to finally loft them, ouch...

Am I the only one that feels the "urge to purge" when the fast spinning camera appears? I wonder if we could be allowed to edit the cameras ourselves?

Thanks for the tips quadcore, :)

Alex Forbin
 
I'm getting some really strange forces with the newest beta (0.838c), I haven't been able to isolate what it is yet.
Sometimes the inertia drops to practically zero, other times the car body acts as though gravity has been momentarily turned up.
Anyone else notice this.

Alex Forbin
 
Tried 0.0838c and didn't see any changes in the track cameras on carlswood and a few other tracks.

Did note that one of my moveables was missing, a braking marker on watkins. Also noted a problem with my bugatti diff Qlog error that I can't fix. Also tracked don't work with it.

IMHO the track cams were faifly good but the 1 to 0 keyboard cams are still the biggest problem. The last ver they were good was 0.0834.
 
I'm wondering what's happening with Newton, have a homemade 2K proxy/collision mesh on my newest damageable Supra RZ & colliding with cones at certain intervals will produce a wrong physical simulation....hmmm, my car hits the cone & depending on the hit angle, sometimes my car just flies away....hmmm not realistic at all !

Since we talking about Newton, had a strange situation yesterday, my car was stuck on a cone, debugging it with the wireframephys=1 or carbbox=1, there's no proxy for the wheels & that's still a mystery to me, how Racer internally handles them, graphically talking we see nothing...

Ruud, wouldn't be it good to give us the ability to insert a collision mesh to our wheels as we do for our car ?
For sure, we couldn't build it & combine it to the car proxy because of the wheels dynamical graphical representation & stuff.
 
Since some days, I was asking myself if I would be able to build a 3D Flash (AS3) car & shader editor...
It seems from the developer answers, that the AS3 3D engine classes handles correctly + 60K cars in ase/dae/3ds format...Maybe Flo (AS3 3D Engine Developper) could say something as I talked with him about Racer some days ago....Merging skills & collaborating together is the solution of almost all our problems, IMHO.

This idea came to me, as I explained him, because getting & building a collection of cars implies quicker customization levels & increased efficiency in dealing with all our car ini variables...

http://3dflashlo.wordpress.com/
The 3rd application is the kind of idea we could have tomorrow...Flash 11 beta required...

Also the dof could be directly loaded into the Flash program to avoid dealing with other formats than the dofs...
There' s a Max script available (already tested) which outputs any 3DS Max mesh into ASCII format in a .as class directly.

The Max Script is called AS3GemClassExporter & works greatly !

http://www.coconnut.com/blog/source/jel/Tutoriales/TutorialAS3GeomClassExporter/script_3ds_max_9.rar
Was also thinking, to use this script to handle custom scripted Racer objects at runtime...

So what you guys think about it, especially Ruud ?

Was thinking that you could implement some code-able AS3 apps directly to Racer, like I explained (& like other games too), but this could apply for custom GUIs or other stuff like 2D animations like the HUD assets...you know nested stuff in AS3 & movieclips (MC)..

All ideas once again ! ;)
 
I'd rather Ruud just take inspiration from little things we have done, and implement these things directly in Racer.

Ie, the Lambo config tool I made really could be programmed into Racer. rFactor has a config front end for cars and it really is just accessing fragments of code in ini files to adjust the car as you see it.
In theory you could probably get a real-time shader value adjustment panel in there so you can scrub rgba values for ambient/diffuse/fresnels etc, after having cycled through the materials/shaders using some other interface (like pgup/pgdn in Racer modeller.exe)

I like the idea of making a tool ourselves, but the issue is Ruud should be doing that kinda thing. I think if we show him cool ideas that work to encourage a direction we would like to see that is cool.
I'm not sure what they thought at Cruden, of my Lambo config tool. I guess for them car config is kinda irrelevant as it's a simulator for them more than a driving 'game' almost, so changing car colours or wheels is kinda irrelevant.

The best bit for me about the Lambo config tool was that it used ini.exe, and all the data for changes is stored in easy to read/run batch files, so very easy to update/change if Racer changes (which it will)
Running big complex compiled Flash will mean another element to maintain, bug-fix, version control, maintain etc etc... ie, Ruud might change one shader a bit and all of a sudden all our flash tool exe's and config tools have to be updated. Arghhhh! Hehe :D

I say let Ruud do it. We can define it, and exactly how it should work, maybe even pseudo code the thing, and then hopefully just let Ruud implement it into the menu system for the Free Racer version :D

Hmmmmmm...


Dave
 
yes & no Dave, Cruden surely is thinking the same, as I would now imagine, it isn't just about colors & stuff, it's about assigning for example custom profiles created via the program which could be swapped/interchanged quickly among cars....:)

With some of the AS3 3D classes, we could easily "hardbody" our cars in the program & have some minimal simulation occurring just in that integrated/external interface, you know just avoiding the endless reloads of scripts & game...

That's why I threw the question, is Racer conscious of itself or its files changes during runtime ?
Not everything....

All links redirects you to the most famous AS3 3D Engines, basically you have PaperVision3D, Sandy3D & Away3D.

Check it out Ruud, maybe some code fixing ideas will emerge in your mind reading the classes code, I suppose your C++ code is using similar methods/techniques to get some of the job done..

http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/
http://www.flashsandy.org/blog/
http://sandy.googlecode.com/svn/trunk/sandy/as3/tags/3.1.1/docs/index.html
http://blog.papervision3d.org/
http://papervision3d.googlecode.com/svn/trunk/as3/trunk/src/org/papervision3d/core/math/
http://www.jiglibflash.com/blog/
http://www.jiglibflash.com/docs/
http://code.google.com/p/jiglibflash/source/browse/trunk/fp11/src/jiglib/?r=222
http://blog.muzerly.com/
https://github.com/away3d/awayphysi...fd0ae683f16b64a22864dec6b9fd5/src/awayphysics
http://www.nulldesign.de/projects/nd3d-as3-3d-engine/
http://nd3d.googlecode.com/svn/trunk/src/
http://www.nulldesign.de/nd3d/docs/index.html
http://books.google.be/books?id=ld2...ce=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
 
Hehe, well apart from Flash & AS3, I have thought about creating a complete customizable front end (that is menus - car selection screen, track seleciton screen, options screens... the works) for Racer in C++ and GLSL. I can already create simple 3D OpenGL games from scratch (programming everything in C++), check out my Pong video for example: http://www.siimannuk.com/preview-of-my-first-c-3d-game/

It's just that firstly, I don't have the time and secondly, this would mean updating the tool as soon as Racer changes...

Hmm...
 
Cool projects ! ;)

I wouldn't know what's retaining us for creating such tool for us all. I was also lately re-executing RacerEng & Raven, just to check all the stuff which was implemented inside. Something like those 2 programs merged together in a new C++ simple & functional 3D framework interfaced or external to Racer.

Maybe we shall open a new thread & unitize ideas together !
 
Whippy's tool that came with his Lambo was great. Something like that or as QCM^ said would be great (even handier if it were already part of the Racer menu) :)
 
I started writing an ini editor in PHP a while back, didn't get too far though. Basically it read in the sections of any racer ini file specified, then gave you a drill down tree thru the sections. It also compared the entries in the specified ini against a known commands list & gave description, min & max values etc for the known values.
 
I'm wondering what's happening with Newton, have a homemade 2K proxy/collision mesh on my newest damageable Supra RZ & colliding with cones at certain intervals will produce a wrong physical simulation....hmmm, my car hits the cone & depending on the hit angle, sometimes my car just flies away....hmmm not realistic at all !

Since we talking about Newton, had a strange situation yesterday, my car was stuck on a cone, debugging it with the wireframephys=1 or carbbox=1, there's no proxy for the wheels & that's still a mystery to me, how Racer internally handles them, graphically talking we see nothing...

Ruud, wouldn't be it good to give us the ability to insert a collision mesh to our wheels as we do for our car ?
For sure, we couldn't build it & combine it to the car proxy because of the wheels dynamical graphical representation & stuff.
I was noticing on Roggel that the lambo tires don't appear to cast a shadow. Is that typical? Also the car shadow seems to be visible through everything even the galvanized steel-clad concrete dividers.
 
secondly, this would mean updating the tool as soon as Racer changes...

Hehe, this is the issue.

It might make sense to develop it when v0.9 comes out, for helping develop content for v0.9 with.

However, I have no issues just tweaking shaders in notepad++ and using 'reload shaders' in Racer... it's not perfect, but it's intuitive and fast enough.

I think I set up all my Lambo colours/shaders for all the different car paints in one evening.


As I've said many times before, if you can make a car, texture it and do that to start with, the extra learning/skills required to set up the shaders (with existing good examples which we do have), should be a cakewalk!

I find making a car the hardest/slowest part. Shaders/tweaking are a piece of cake in comparison :D



I just think Ruud needs to implement a system like rFactor uses. We can write the ini fragments (like the Lambo mods), and run them in the Racer selection menu...
It'd be better yet to do it that way because we could ask Ruud to also seed the users car.shd and car.ini values to host machines during multiplayer, so other people see their car in the right colour too!

Stuff like that won't ever get done if we make external tools etc. As said, best to try help Ruud with ideas/pseudo code so he can implement the systems we want into Racer for us more easily. Stand alone will always be a compromise.


Dave
 
Oh, sorry, I was mostly using flags=0 (plain distance-to-camera-based) zooms. I'll have to give the zoomdot ones a try.

I'll think about how it should work on [-1, 1] to go better with zoom_far.

I added zoomFar in a similar way:

Code:
  } else if(flags&ZOOMDOT)
  {
    // Interpolate from zoomEdge->zoomClose->zoomFar
    float kEdge,kClose,kFar;
    const float fudge=0.15f;

    kClose=zoomClose/90.0f/fudge;
    if(normalizedDistance<0)
    {
      // Before the camera
      distance=-distance;
      kEdge=zoomEdge*radius/90.0f;
      zoom=90.0f*(d3Lerp(kClose,kEdge,d3Min(distance/radius,1.0f)))/(distance+fudge);
    } else
    {
      // After the camera
      kFar=zoomFar*radius/90.0f;
      zoom=90.0f*(d3Lerp(kClose,kFar,d3Min(distance/radius,1.0f)))/(distance+fudge);
    }
    zoom=d3Min(zoom,zoomClose);
  } else
 
Also Ruud, one other thing I wanted to bring up issue with was the panorama shader. The scale variable didn't seem to work intuitively. I'm not sure if you developed it or just quickly added it. I'll try do some tests again to show why it wasn't working for me with images. (I made some tweaks to make it work as you'd expect, but not sure if it's right :) )

Try these 2 shader files (rename to .cg). They put the scale in the vertex shader, rather than the fragment shader. Since the extinction factor has an exp() inbetween, scaling inside the fragment shader requires you to deal with the exp(), but not in the vertex shader.
Let me know if that is easier to tweak.
 

Attachments

  • panorama2_f.txt
    1.5 KB · Views: 356
  • panorama2_v.txt
    1.8 KB · Views: 354
Ah, I didn't think to look there. I tried it but it made no difference, there's still an increase of about 40% once I pause/unpause the game
and it affects all cameras not just the incar.
I've had confirmation from others on this forum that they too are having the problem, otherwise I would be looking at my system. Could it be a directx problem?

Alex Forbin

I've uploaded a test version with fmod 4.30 (the old one) at http://racer.nl/temp/racer_0838audio_bug.7z
Download that, put the files in Racer's directory and rename fmodex430.dll to fmodex.dll (FMOD won't complain if the DLL is NEWER, so check the filesizes). FModex.dll v4.30 is 385Kb big, v4.36 is 780Kb.
See if that resolves the audio issue and let me know.

EDIT: please redownload the above .7z! (5:56pm here in Holland). It was really mostly a v4.36 load still, now it is the real FMod4.30; it should not work with the newer fmodex.dll, only with the 4.30 fmodex.dll
 
I just think Ruud needs to implement a system like rFactor uses. We can write the ini fragments (like the Lambo mods), and run them in the Racer selection menu...
Dave

:) It's already there !

Basically, as I explained earlier, Racer awesome console commands lets you create ANY INI FILE on fly & you can create some cool stuff with it, since it can hold anything, that's what my script is doing when hardcoding my car trajectory into waypoints I'm reusing later with the setters....

Same occurs with the ini exe Racer tool, where you just take full control over it, you can write/read & remove some tree.

:D using now the new scripting framework & you should be able to do a lot of things with some imagination !
For example, instead of using the TOD via its curve file, you could re-create it in an ini file with all the custom variables + with snow/rain/etc..& use it in your scripts.

Another cool example would be to try out real snow with movables & joints/skeletons, you remember my tree example ? the same idea but for snow, that means creating a snow flake (real thin closed rectangular shape like mesh) + with the most littlest sphere collision mesh assigned to it (via Tracked) to finally use it ingame & distribute them via scripting.

Those little spheres would then interact 'naturally' with car tyres, make somehow the whole situation real...without decreasing grip :) ? Sure, our skin shader would probaly need some texture alpha tweaking, which I wasn't able to quickly mod in the shader. Maybve Stereo, Cam or Some1 or anyone else wanting to try some crazy ideas...hehe

@Radome
Yeah I also noticed some changes in CSM, but didn't check/compared everything in the shaders code yet...
As per tyres shadows, theoretically they shouldn't cast any shadows imho, since they are planar projections.
 

Latest News

Online or Offline racing?

  • 100% online racing

    Votes: 70 7.3%
  • 75% online 25% offline

    Votes: 99 10.4%
  • 50% online 50% offline

    Votes: 139 14.5%
  • 25% online 75% offline

    Votes: 265 27.7%
  • 100% offline racing

    Votes: 379 39.6%
  • Something else, explain in comment

    Votes: 4 0.4%
Back
Top