1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Animation tutorial online for v0.8.9

Discussion in 'Racer' started by Ruud, Jun 18, 2010.

  1. Ruud

    Ruud
    RACER Developer

    I've just uploaded an elaborate tutorial online about adding animated objects to Racer tracks. You can find it at http://racer.nl/tutorial/animation.htm

    In a similar way I intend to document how animated steering (hands) is done. That is a bit different since you need to match the animation to the steering angle and ofcourse includes some precise hints on how to integrate it into a car.

    You do NOT need 3D Studio Max to complete the tutorial, but you will need it to create your own animations.
     
  2. HAHAHA" That boy dancing is awesome and funny =D
     
  3. This is just what is was thinking about last night, how strange a coincidence.
    I wanted - and now can - add animated animals to Lime Creek Nature Park :)

    Thanks Ruud.
     
  4. Now if some one can convert the Tutorial for Blender...
     
  5. Hehe, that is really cool.

    With trigger lines you could do some quite cool stuff with people running into the road.

    Ie, a few urban streets with cars parked around and people walking at the sides, but every so often a kid might run out and you have to stop.

    Could be quite a cool safety tool.



    Anyway, moving away from that, Ruud, is there any reason why movables are now in geometry.ini and not in the movables001.ini?

    movables.ini files gave us the ability to have the track layout/settings /config fixed, and then just tinker and test with movables configs...

    That would be great for a racing track with spectators but different times of day, cone layouts, barrier layouts on a multi-course city track... having geometry.ini and movables separate seems a prudent thing to do. My geometry.ini files get pretty large just with main polygons and LOD's for grass etc, but with my hundreds of cone entries as well it is just silly.

    Ie, if I update all my grass LOD polygons with a new naming convention, stripping and re-importing, flagging, and doing the LOD data inside the four geometry.ini files I have that are just for different cone layouts is just silly.
    I know I'm doing things in the wrong order, but it's a development track. The single geometry.ini file isn't helping me from a development point of view.



    It was great with movables001...999.ini. Why was that abandoned?

    Dave
     
  6. Lol Dave => "It was great with movables001...999.ini. Why was that abandoned?"

    You got the answer to your question, I also asked myself if materials should be in their own files (like in Shift), finally I'm convinced about Ruud methods, regrouping things to one file (shd) to avoid dealing with too many files...

    Same thing when 3D modeling & exporting to DOFs, I used to regroup meshes together without any problems when outputting the content to Modeler.

    I'm agree with you, Racer could be GTA 4 or LFS 2 or whatever you imagine, the fact we have triggers, makes a huge difference...in developping game logic !
     
  7. Nice, good way to implement intelligent traffic in racer ! :D
     
  8. Well, there are pros and cons. Having a feature there that doesn't have to be used isn't damaging developers unless they want that complexity for larger projects.


    For example, like in the head of shader files, or defining pacejka sets for car tyres, we can nest common data. This is fantastic for movables, since if we have 200 cones on a track then we can condense 200 entries for hit box type, inertia and mass, in one place.
    However, currently, Racers trackEd tool will unravel ALL nested information, even if it information in that files is not altered.

    That alone makes a 5kb movables file a 70kb movables file and much harder to change a simple inertia or mass value for the cones.

    Throw that information into the geometry.ini file and suddenly you have a mess you don't even want to begin editing either in trackEd or by hand!


    These are not problems in an environment where you are not developing but simply pushing ONCE to a final build... but they are massive problems when you don't know how much inertia to set for your cone types, or tyre types, or what bounding box types change the performance best, or simply testing and looking for bugs.

    So it's not so much about having too many files, but having the ability to break things up sensibly to make development/bug fixing nice and easy, and give that content flexibility in deployment.


    Right now I have about 10 cone layouts on my track for various test layouts or track layouts, but rather than store 10 small 5kb files that users can happily swap in and out of the folder, I have to have 10 large geometry.ini files that ALL have to store 95% of the same data, be maintained as such, just to have the different layouts.
    Ideally I want MORE layouts and more custom things like scripts running for each one too (to reset the slaloms etc), but it's just mad trying to bug-fix and develop and maintain 10+ geometry.ini files when I only really want to be editing a tiny part of it for these things.

    It's a difficult situation. Ruud has historically added things that give flexibility but then removed them for clarity, when they were no harm simply being passive features IF people still wanted to use them.

    I believe this is a case where movables.ini files could be used by an author to allow more flexible diverse content, be put in the track skins folder on their own, and the data found in them is simply appended to the geometry.ini at runtime :D (Ruud has mentioned this is easy and it makes sense :) )


    I'm all one for simplicity and clarity, but development speed and flexibility are also important in a development environment where we have no 'formal' tools to use that allow us easy management of these HUGE data sets and entries we end up with!

    Everything post 3D export is currently lossy in Racers development environment. Stuffing everything into one big ini file is then even more demanding on developers time... then having the Racer tools destroy nesting to make life even HARDER during development is even more silly :D :)


    I think things should be able to be all together OR split up, to make the life easier for developers... ie, the addition of multiple models for a cars body improved artistic possibilities massively, yet it didn't add complexity for those who didn't want to use it, they simply ignored it :)

    Dave