FreeGameDev

Also, what are you going to do:
* Change the materials.xml structure? i.e.
<material name="bison.png" texture-effect="transparency" ignore="Y"/>
-> Change of source code required
* Keep XML unchanged
-> Change in track exporter required

Hi,

I coded a new way for the XML file :

compositing="none"
compositing="blend"
compositing="test"
compositing="additive"

this should be a better syntax (the old syntax is still supported so there is no need to re-export everything)

Hi asciimonster,

thanks for the latest changes
If you don't mind, we have a few more properties

I recently added a new option to disable writing to the Z buffer. The syntax is

{l Code}: {l Select All Code}

disable-z-write="Y"/"N"


The default is "N".

And we have another larger change : STK now supports particles when driving and when skidding (which replaces the old "graphical-effect" property). The syntax looks like :

{l Code}: {l Select All Code}

<material name="chess.png">
    <particles base="smoke.xml" condition="skid" />
  </material>
  <material name="snow.png" max-speed="0.4" slowdown-time="0.8">
    <particles base="smoke.xml" condition="skid drive" />
  </material>


So each material would need a way to specify a type of particles (if any), which could be a simple text box where you type the name of the XML file. Then there is also the "condition" property that says when particles are emitted; the current allowed values are "skid" and "drive" (and combinations of the two).

Do you think this would be possible?

Auria {l Wrote}:I recently added a new option to disable writing to the Z buffer.

No Problem

Auria {l Wrote}:And we have another larger change : STK now supports particles when driving and when skidding (which replaces the old "graphical-effect" property).

Hmm. Another nested structure (like sfx). That requires changes to the track exporter.

Auria {l Wrote}:So each material would need a way to specify a type of particles (if any), which could be a simple text box where you type the name of the XML file.

I have something better: Make it a file picker (type_URL, e.g. the property "music"), so you won't even need to type the name of the XML file...

Auria {l Wrote}:Then there is also the "condition" property that says when particles are emitted; the current allowed values are "skid" and "drive" (and combinations of the two).

Hmm. Picklists are programmed to be mutually exclusive... I'll have to ponder some more.

Auria {l Wrote}:Do you think this would be possible?

As I always say at work: Everything can be programmed on a computer, it just a question if you want to (time- and money-wise).

What is the advantage of this script :
Making tracks easily ? so in which points
Reading more easily track already made ?
...more ?

how can we use it ?
I really want to use it as soon as possible

asciimonster, sure, when I said "do you think it's possible", I really meant "do you think you want to work on this" Don't get me wrong, your contribution is highly regarded and we're very glad that you work on this

I also found another minor bug : when you open the browser, if fog is enabled, the fog options don't appear, you need to disable fog then enable it back.

STKRudy85: yes the goal is to make it easier to make tracks. And how to use the browser is covered in http://supertuxkart.sourceforge.net/Track_Maker's_Guide (see "Track-wide properties", "Materials")

STKRudy85 {l Wrote}:What is the advantage of this script :
Making tracks easily ? so in which points
Reading more easily track already made ?
how can we use it ?
I really want to use it as soon as possible

I've made a wiki page just for the property browser, pictures included. It contains the answers to all your questions.

Auria {l Wrote}:I also found another minor bug : when you open the browser, if fog is enabled, the fog options don't appear, you need to disable fog then enable it back.

I'm not quite sure what you exactly mean by "opening the browser". And as such, I am not able to replay this bug. Could you give me some more details to work with?

asciimonster {l Wrote}:

Auria {l Wrote}:And we have another larger change : STK now supports particles when driving and when skidding (which replaces the old "graphical-effect" property).

Hmm. Another nested structure (like sfx). That requires changes to the track exporter.

Yes, I am happy enough to do that, once you have defined the easiest way of storing the information in the properties.

Cheers,
Joerg

asciimonster {l Wrote}:I'm not quite sure what you exactly mean by "opening the browser". And as such, I am not able to replay this bug. Could you give me some more details to work with?

By "opening the browser", I just mean clicking on "STK Browser" in the "Help" menu after opening the track in blender

Auria {l Wrote}:By "opening the browser", I just mean clicking on "STK Browser" in the "Help" menu after opening the track in blender

My guess is that you opened an "old" file, in which the fog variable is/was defined as zero/non-zero. Could you check by opening that file in its original state and look at the value of "fog" with the ID Property browser?

asciimonster {l Wrote}:

Auria {l Wrote}:By "opening the browser", I just mean clicking on "STK Browser" in the "Help" menu after opening the track in blender

My guess is that you opened an "old" file, in which the fog variable is/was defined as zero/non-zero. Could you check by opening that file in its original state and look at the value of "fog" with the ID Property browser?

You're right, now it works correctly, ok

Ok. After a long think and some trial and error I now have a solution that works. (Still looking at better solutions)

Now that the materials.xml file is going be a nested XML, maybe it's better if you also promote the zipper items to a separate node:

{l Code}: {l Select All Code}

<material name="...">
   <sfx .../>
   <particles ... />
   <zipper ../>
</material>

Hi asciimonster,

maybe you can explain a bit more, I'm not sure I understand what you're proposing?

The current structure looks like:

{l Code}: {l Select All Code}

<?xml version="1.0"?>
<materials>
   <material name="..." compositing="..." clamp="..." light="..." sphere="..." anisotropic="..." backface-culling="..." max-speed="..." slowdown-time="..." ignore="..."  reset="..." disable-z-write="..." graphical-effect="..." reset="..." zipper="..." zipper-duration="..." zipper-max-speed-increase="..." zipper-fade-out-time="..." zipper-speed-gain="...">
      <sfx filename="..." name="..." rolloff="..." min-speed="..." max-speed="..." min-pitch="..." max-pitch="..." positional="..."/>
      <particles base="..." condition="..."/>
  </material>
</materials>


The nodes sfx and particles are trigged by two conditions: "sound-effect" and "particle", respectively. However, there is a third conditional group in the above example: zipper

I suggest using zipper=Y/N as a trigger for a third XML node under matrerial, so that we can do away with the zipper- prefix:

{l Code}: {l Select All Code}

<?xml version="1.0"?>
<materials>
   <material name="..." compositing="..." clamp="..." light="..." sphere="..." anisotropic="..." backface-culling="..." max-speed="..." slowdown-time="..." ignore="..."  reset="..." disable-z-write="..." graphical-effect="..." reset="...">
      <sfx filename="..." name="..." rolloff="..." min-speed="..." max-speed="..." min-pitch="..." max-pitch="..." positional="..."/>
      <particles base="..." condition="..."/>
      <zipper duration="..." max-speed-increase="..." fade-out-time="..." speed-gain="...">
  </material>
</materials>

Looking at the amount of XML attributes, I also suggest turning them into XML nodes (this is in congruence with the other STK XML structures).

{l Code}: {l Select All Code}

<materials>
   <material>
      <name>...</name>
      <compositing>...</compositing>
      <clamp>...</clamp>
      <light>...</light>
      <sphere>...</sphere>
      <anisotropic>...</anisotropic>
      <backface-culling>...</backface-culling>
      <max-speed>...</max-speed>
      <slowdown-time>...</slowdown-time>
      <ignore>...</ignore>
      <reset>...</reset>
      <disable-z-write>...</disable-z-write>
      <graphical-effect>...</graphical-effect>
      <reset>...</reset>
      <sfx>
         <filename>...</filename>
         <name>...</name>
         <rolloff>...</rolloff>
         <min-speed>...</min-speed>
         <max-speed>...</max-speed>
         <min-pitch>...</min-pitch>
         <max-pitch>...</max-pitch>
         <positional>...</positional>
      </sfx>
      <particles>
         <base>...</base>
         <condition>...</condition>
      </particles>
      <zipper>
         <duration>...</duration>
         <max-speed-increase>...</max-speed-increase>
         <fade-out-time>...</fade-out-time>
         <speed-gain>...</speed-gain>
      </zipper>
  </material>

Hi,

moving "zipper" to an attribute is sure possible and desirable

Regarding using more of <attribute>...</attribute> format, the issue is that our current XML-reading class is not very friendly with that format, so for now, to save us time, I'd prefer to keep the attributes as they are

Auria {l Wrote}:Moving "zipper" to an attribute is sure possible and desirable

Blink and it is done. I could never say no to a lady.

Auria {l Wrote}:Regarding using more of <attribute>...</attribute> format, the issue is that our current XML-reading class is not very friendly with that format, so for now, to save us time, I'd prefer to keep the attributes as they are

That's ok then. However, you are getting you XML naming confused. In <abcd efgh="hello"/> abcd is called a node and efgh is called an attribute.

asciimonster {l Wrote}:

Auria {l Wrote}:Moving "zipper" to an attribute is sure possible and desirable

Blink and it is done. I could never say no to a lady.

While I agree with the design, we should update the track version numbers, since old versions (i.e. 0.7) won't be able to read newly exported files correctly. And we have to see if we can/should support both styles in stk, otherwise we have to re-export all tracks (which we probably have to do anyway in order to get the particle information into the blend files).

Cheers,
Joerg

Hi,

ok, I've just updates stk to read the new zipper format, and added a new track version (4) number in the track exporter (though track versions 3 can still be read).

I noticed two problems at this stage:

• The fog folor is written as floating point values; while STK expected [0-255]. Is there an advantage of FP numbers? Otherwise I'd suggest to change the track exporter to write the old format, but we could fix this in stk as well (though then we would more work to stay backwards compatible).
• I am not sure if the weather effect (rain) can be specified in the browser. If so, I didn't realise how to do this.

One additional question: should we perhaps combine the browser and track exporter into one script (or at least add a button to the browser to run the exporter)? One file would be a bit big, but would have the advantage that it's easier to run this while testing and debugging (if they need to be installed in blender .script directory, we would have to restart blender).

Thanks a lot for the improvements!
Joerg

hiker {l Wrote}:The fog folor is written as floating point values; while STK expected [0-255]. Is there an advantage of FP numbers? Otherwise I'd suggest to change the track exporter to write the old format, but we could fix this in stk as well (though then we would more work to stay backwards compatible).

Please note that most of the time I have no clue what format a varible has. It is not documented anywhere, so I have to guess from the context. I try to test every option for functionality. Since this is the second time someone has alerted me to an incorrect formatting, I seem to be doing ok.

The decimal color system is just the internal representation of blender. Changing it's representation should not be a problem.

hiker {l Wrote}:I am not sure if the weather effect (rain) can be specified in the browser. If so, I didn't realise how to do this.

If you look into the code you'll see that all properties (lPropertyDef) are defined by its type. As long as it falls within one of the available types (string, integer, float, color, boolean, static, picklist, url and imageurl) there is no problem. If more types are needed, please tell me. I do not forcast any problems adding a weather property (get it? Weather <-> forcasting? )

After adding a property, don't forget to add it to it's type (lSTKTypes2Properties).

hiker {l Wrote}:One additional question: should we perhaps combine the browser and track exporter into one script (or at least add a button to the browser to run the exporter)? One file would be a bit big, but would have the advantage that it's easier to run this while testing and debugging (if they need to be installed in blender .script directory, we would have to restart blender).

Personally I was playing with the idea of having the two scripts share a common dataformat (in a separarte file). The exporter now has a pull model: The script deremines which values to read. I was contemplating making it a push (or data-driven) model: The data makes the exporter write XML code.

The "make track now" button is a good idea that should be easy to make. If we want to change things later there should be no problem.

hiker {l Wrote}:Thanks a lot for the improvements!

You're welcome!

Hi,

for weather effects I suggest you just add a browser property, "weather=" and you can select the name of a XML file describing weather particles.

@Joerg: I know I expressed a need to define the size and location of the editor, but wait before coding that, I'm experimenting with a new camera-relative technique that should be easier to export as well as easier on the CPU/GPU. So if you want to work on something, check the water splash effect first

Auria {l Wrote}:for weather effects (...) an XML file describing weather particles.

(...) I'm experimenting with a new camera-relative technique that should be easier to export as well as easier on the CPU/GPU.

I tried the new particle weather effect from SVN, and was not impressed. It sucked processing power, big time. Isn't it much better using an overlay effect than a full particle effect within teh 3D environment?

Weather effects etc should be done exclusively with shaders so decent GPUs can shine and older 3D cards can ignore them.

The current weather effects are experimental, more work is to be done on this

Since the sourceforge SVN server still does not allow commits, I'm posting my changes here.

asciimonster {l Wrote}:Since the sourceforge SVN server still does not allow commits, I'm posting my changes here.

Asciimonster, for the water effects auria has recently added, we need one more feature: the water effect is not actually given to the water surface (since the karts will likely be 'in' the water, so we can't easily detect that), but to the ground the kart is driving on. But to get good water effects then, we need to specify where to start the water effect (since if we start them where the wheels are, that would be under the water). So our current (simplified) idea is that you can specify a second objects for an object with water effect, and the kart exporter will then compute the difference in height, and this will be used to offset the start location of the water. This is not perfect, but we hope that this will look good enough.

Do you think this could be added to the property browser? I am happy to add the exporting, I just need to know which other object should be used.

Cheers,
Joerg