Racetrack (conversion)

[Auria]

Yes, skeletal means with armatures. This is mostly useful for meshes that need to be deformed. IPO animation (using keyframes) is preferred otherwise - the track exporter will take care of exporting the animation as long as you set the type to be animated, as described on the wiki

[Pixel]

Ok, cool. Is there a way to set animation speed?

[hiker]

Ok, cool. Is there a way to set animation speed?

Animation speed is taken from the fps value defined in blender.

Cheers,
Joerg

[Pixel]

Hello, hiker. Good to see you back

So, if I want say a 10 second animation, do I set the FPS in the Render Panel to 60, then set
the length of the animation as 1 - 601, just like I would if I wanted to animate the object
in Blender itself?

[hiker]

So, if I want say a 10 second animation, do I set the FPS in the Render Panel to 60, then set
the length of the animation as 1 - 601, just like I would if I wanted to animate the object
in Blender itself?

Yes, or just use the default (of 25 fps iirc), and use the frames 1 - 251, or ...

That should all work - any problems, let me know.

Cheers,
Joerg

[Evolution]

Maybe you can use a texture for the stands (Is this the right word? I did not know the right translation of the German "Tribüne" and used the Google translator. )

[Pixel]

I'm still working on the animation, but I haven't quite got it to my liking yet.

I'm starting to build some walls around the track. I want to put some images on the walls,
like they sometimes do on real courses. I'm not sure how to handle asking about them.

Do I still need an author's explicit permission if the image(s) I wish to use is (are) already
incorporated into STK elsewhere?

[stked]

I doubt it, but I'm not sure.

[Auria]

I'm still working on the animation, but I haven't quite got it to my liking yet.

I'm starting to build some walls around the track. I want to put some images on the walls,
like they sometimes do on real courses. I'm not sure how to handle asking about them.

Do I still need an author's explicit permission if the image(s) I wish to use is (are) already
incorporated into STK elsewhere?

Hi,

it's all a question of license. The data already present in STK is already most/all under an open license. So re-using material from STK is almost always fine, you just need to create a License.txt file or so to give credit to the author and write the license of the files

[Pixel]

Would it be possible to add support for multiple UV textures on the same face? I tried it while
developing the Stadium, and it didn't work. IIRC, trying to use two UV textures on the same face
made the object disappear.

[Auria]

Pixel: I'm not that good at blender, but I can't see how multiple UVs should work? they should blend together?

[Pixel]

UV is very difficult. I've dabbled in Blender since it was part of NaN, and I still know far less about UV (and Blender itself) than I'd like.

As for multiple UV textures sharing the same face, my original idea was to layer one texture on top of another.

Example: I have two textures-

a brick wall texture
a red arrow texture

Suppose I want to display a red arrow on a brick wall. I could open an image editor, add the arrow image to the brick wall image,
and save a new copy for my texture. Then apply it in Blender to the wall face as a single UV texture. That would work, but what if I need to
change the wall, without changing the arrow? Or if I want to use my arrow on a sign instead? Not only that, the new combined
image, in addition to the original brick wall texture increases the file size overhead of the track.

I believe using multiple UV's per face could solve this problem more elegantly, and possibly provide other benefits. I only attempted to use
two UV textures on the same face(s) once that I can remember, I need to do some more experimenting to see how the two textures interact
with each other in Blender.

I believe this is a feature that should be considered, though I may some time to produce a more detailed concept.

[acme_pjz]

I think multiple UV textures are supported in Irrlicht (at least DirectX )

[hiker]

I think multiple UV textures are supported in Irrlicht (at least DirectX )

I think we need a special material type to set in this case, which specifies how the textures affect each other. I have some other things to do first before I can have look - e.g. EMT_SOLID_2_LAYER ... which apparently is not implemented for OpenGL, but I have to check this, sometimes comments are outdated ).

Cheers,
Joerg

[acme_pjz]

I think we need a special material type to set in this case, which specifies how the textures affect each other.

Maybe simplest situation is the texture you want to blend has alpha channel, e.g. the red arrow texture has alpha channel, and blending on the brick texture ...

In Direct3D this called "TextureStage", but I don't know its name in OpenGL and Irrlicht ...

[Pixel]

I'm having trouble deciding what to call it. Maybe "Layered UV Texturing"?

I started experimenting with it back when I was working on the test case track now called the Stadium.

IIRC, using Blender's texture channels to layer UV textures caused the whole object to disappear in STK. Unforunately,
I did not keep the original, but I attached an approximation of it to this post. NOTE: You will need the original images
from the Stadium as already incorporated into STK. I did not include them because of my low bandwidth connection.

Here's a brief listing of what's in the attached file.

BLEND file - for analysis of how layered UV's can be done in Blender (NOTE: The process doesn't have to be done
exactly like this, but it should be pretty close.

Rendered image - For some reason, Blender does not correctly display the layers in the real-time 3D view by default,
only the active layer. (I haven't figure out how to change this.) I've included this render to show that the textures are
layered. I apologize for the poor render quality. I had to add a camera to get the scene to render at all, and I didn't add
any lights to keep things simpler.

B3D - I have no idea how to interpret this file. While it might be possible to implement layered UV's without it, file format
support should IMO make it considerably easier.

Screenshot - I've only apllied the experimental texturing in one place, the left hand starting position. (IIRC, the is Starting position 1)
anyway, this shows the "active" UV layer on the object.

image (start_p1.png) - the top layer texture itself. The quality is not so good, but it does demonstrate the basic idea. The image has BG alpha,
as acme_pjz mentioned.

It looks like the same object can have different UV maps for the same face(s) using this method. To me that is the most important aspect.

I really feel this is something that should be implemented, if possible. It's a little bit tricky, but a good Blender artist (NOT myself)
could do some neat things with this. I think this should be entirely optional however, the usual method of doing UV textures should
continue to function as-is.

If layered UV is not implemented for OpenGL in Irrlicht, I think it should be. I'm NOT a developer though, just a would be Blender artist.

If it's not implemented in OpenGL in some way, I would be floored. From an artistic perspective, it's just something a general purpose
3D API should have.

[acme_pjz]

I think Irrlicht is supporting multi texture stage render, because there is an index argument in SetTexture function ... But I don't know whether .b3d file support this feature
BTW , I see there is a function call "irr_driver->getAnimatedMesh(full_path);" in Track::loadMainTrack, after that do you need to load texture files manually? If the answer is no, then maybe the source code needn't to change, just export .b3d file with multi texture stage

It looks like the same object can have different UV maps for the same face(s) using this method. To me that is the most important aspect.

At least supported in Direct3D This called "multi texture coordinates" ...

[hiker]

I think Irrlicht is supporting multi texture stage render, because there is an index argument in SetTexture function ... But I don't know whether .b3d file support this feature
BTW , I see there is a function call "irr_driver->getAnimatedMesh(full_path);" in Track::loadMainTrack, after that do you need to load texture files manually? If the answer is no, then maybe the source code needn't to change, just export .b3d file with multi texture stage

The b3d file should support this, and as I have written irrlicht does support multiple textures, but the problem is how to interpret the different textures. Irrlicht offers the following settings (from include/EMaterialTypes.h, but only the entries that do not explicitly mention that they only do one texture):

{l Code}: {l Select All Code}

                //! Solid material with 2 texture layers.
                /** The second is blended onto the first using the alpha value
                of the vertex colors. This material is currently not implemented in OpenGL.
                */
                EMT_SOLID_2_LAYER,

                //! Material type with standard lightmap technique
                /** There should be 2 textures: The first texture layer is a
                diffuse map, the second is a light map. Dynamic light is
                ignored. */
                EMT_LIGHTMAP,

                //! Material type with lightmap technique like EMT_LIGHTMAP.
                /** But lightmap and diffuse texture are added instead of modulated. */
                EMT_LIGHTMAP_ADD,
! More lightmap settings skipped
              //! Detail mapped material.
                /** The first texture is diffuse color map, the second is added
                to this and usually displayed with a bigger scale value so that
                it adds more detail. The detail map is added to the diffuse map
                using ADD_SIGNED, so that it is possible to add and substract
                color from the diffuse map. For example a value of
                (127,127,127) will not change the appearance of the diffuse map
                at all. Often used for terrain rendering. */
                EMT_DETAIL_MAP,
                //! A reflecting material with an optional non reflecting texture layer.
                /** The reflection map should be set as first texture. */
                EMT_REFLECTION_2_LAYER,

                //! A transparent reflecting material with an optional additional non reflecting texture layer.
                /** The reflection map should be set as first texture. The
                transparency depends on the alpha value in the vertex colors. A
                texture which will not reflect can be set as second texture.
                Please note that this material type is currently not 100%
                implemented in OpenGL. */
                EMT_TRANSPARENT_REFLECTION_2_LAYER,

                //! A solid normal map renderer.
                /** First texture is the color map, the second should be the
                normal map. Note that you should use this material only when
                drawing geometry consisting of vertices of type
                S3DVertexTangents (EVT_TANGENTS). You can convert any mesh into
                this format using IMeshManipulator::createMeshWithTangents()
                (See SpecialFX2 Tutorial). This shader runs on vertex shader
                1.1 and pixel shader 1.1 capable hardware and falls back to a
                fixed function lighted material if this hardware is not
                available. Only two lights are supported by this shader, if
                there are more, the nearest two are chosen. */
                EMT_NORMAL_MAP_SOLID,
                //! A transparent normal map renderer.
                /** First texture is the color map, the second should be the
                normal map. Note that you should use this material only when
                drawing geometry consisting of vertices of type
                S3DVertexTangents (EVT_TANGENTS). You can convert any mesh into
                this format using IMeshManipulator::createMeshWithTangents()
                (See SpecialFX2 Tutorial). This shader runs on vertex shader
                1.1 and pixel shader 1.1 capable hardware and falls back to a
                fixed function lighted material if this hardware is not
                available. Only two lights are supported by this shader, if
                there are more, the nearest two are chosen. */
                EMT_NORMAL_MAP_TRANSPARENT_ADD_COLOR,

                //! A transparent (based on the vertex alpha value) normal map renderer.
                /** First texture is the color map, the second should be the
                normal map. Note that you should use this material only when
                drawing geometry consisting of vertices of type
                S3DVertexTangents (EVT_TANGENTS). You can convert any mesh into
                this format using IMeshManipulator::createMeshWithTangents()
                (See SpecialFX2 Tutorial). This shader runs on vertex shader
                1.1 and pixel shader 1.1 capable hardware and falls back to a
                fixed function lighted material if this hardware is not
                available.  Only two lights are supported by this shader, if
                there are more, the nearest two are chosen. */
                EMT_NORMAL_MAP_TRANSPARENT_VERTEX_ALPHA,

                //! Just like EMT_NORMAL_MAP_SOLID, but uses parallax mapping.
                /** Looks a lot more realistic. This only works when the
                hardware supports at least vertex shader 1.1 and pixel shader
                1.4. First texture is the color map, the second should be the
                normal map. The normal map texture should contain the height
                value in the alpha component. The
                IVideoDriver::makeNormalMapTexture() method writes this value
                automatically when creating normal maps from a heightmap when
                using a 32 bit texture. The height scale of the material
                (affecting the bumpiness) is being controlled by the
                SMaterial::MaterialTypeParam member. If set to zero, the
                default value (0.02f) will be applied. Otherwise the value set
                in SMaterial::MaterialTypeParam is taken. This value depends on
                with which scale the texture is mapped on the material. Too
                high or low values of MaterialTypeParam can result in strange
                artifacts. */
                EMT_PARALLAX_MAP_SOLID,

                //! A material like EMT_PARALLAX_MAP_SOLID, but transparent.
                /** Using EMT_TRANSPARENT_ADD_COLOR as base material. */
                EMT_PARALLAX_MAP_TRANSPARENT_ADD_COLOR,

                //! A material like EMT_PARALLAX_MAP_SOLID, but transparent.
                /** Using EMT_TRANSPARENT_VERTEX_ALPHA as base material. */
                EMT_PARALLAX_MAP_TRANSPARENT_VERTEX_ALPHA,


So my understanding is that you want EMT_SOLID_2_LAYER, which is not supported (atm) with OpenGL. Not sure if you could use EMT_DETAIL_MAP (which was recommended in the irrlicht forum somewhere). Or if any of the other material types would help - let me know which one you need and we will support for this to stk.

It looks like the same object can have different UV maps for the same face(s) using this method. To me that is the most important aspect.

At least supported in Direct3D This called "multi texture coordinates" ...

EMT_SOLID_2_LAYER does not use two texture coordinates, but my understanding is that the other materials do.

Hth,
Joerg

[Pixel]

It might be possible to use OpenGL calls to set up the texture blending. Or is it a bad idea to mix direct OpenGL calls with the Irrlicht API?

[acme_pjz]

Bad news ...

EMT_SOLID_2_LAYER blends the second texture onto the first, but using *vertex* alpha They should use second texture's alpha ... So not this mode.

EMT_DETAIL_MAP not right. If use this mode the road sign will become gray and weird

I checked EMaterialTypes.h and found that there are no proper texture mode ... Such a simple texture blending feature should support in Irrlicht ... Maybe you should ask some questions in Irrlicht forum, or add code to Irrlicht manually (But I don't know OpenGL programming )

[Pixel]

I should say that I can code some in FreeBASIC, and it does have an Irrlicht wrapper, albeit an unofficial one.
Irrlicht as a whole seems way over my head. I'm not really sure how to make C(++) code into FreeBASIC code either.

I have tried to dig around in the Irrlicht docs, and I found a couple of pages that might be relevant.

Doc For SMaterialLayer
Doc For SMaterial

What I don't understand is, there should be some interface for blending the layers together. It's not clear to me this is
what the blend modes in EMaterialTypes are for. But where else would they be?

I wish I understood C code.

EDIT: I've studied the Irrlicht docs a bit more. I've been interested in EMT_ONETEXTURE_BLEND, a relative of EMT_SOLID_2_LAYER.
Looking at the documentation, EMT_ONETEXTURE_BLEND normally uses EMT_TRANSPARENT_VERTEX_ALPHA "as base material".

Another part of the doc mentions E_ALPHA_SOURCE in connection with EMT_ONETEXTURE_BLEND. Here's the link-

E_ALPHA_SOURCE

It lists EAS_TEXTURE as "Use texture alpha channel." Could this be what we're looking for?

[acme_pjz]

I searched in Irrlicht forum, maybe Irrlicht really doesn't support this feature ...

[Pixel]

I know it's been a long time, but I've been stumped on a problem, and I still haven't totally worked out a solution.

I've attached a track update below. NOTE: extract the files into a folder named racetrack in your data/tracks directory. NOTE: Be sure not to use a data folder
containing data for STK 0.6!

It's still not fully complete, and it has some technical problems. I believe I can fix most of them however.


Where I've been stumped is preventing shortcuts. I've put walls around the outside of the track, and some on the inside. Right now they are plain and ugly, but I want to dress them up with images similar to the walls on some actual race courses. Is this an acceptable solution? I realize of course I'll have to watch the licensing.

I may have waited too late to mention this for 0.7, but I hope it will be considered. It's not absolutely necessary for this release, however. When you come out of the tunnel, the track loops around to where you can see a large billboard mounted in front of the tunnel wall. This billboard has a simple texture as a placeholder right now. I intended to put something on it that would serve as a live update for the spectators in the grandstand on the opposite side.

I haven't decided what it could be however. Racing cam showing certain point(s) along the track? Live updated standings list? The standings list might be easier in some ways, though
I'm not sure what the resulting texture should look like.

I should've come forward with this idea sooner I admit. Like I said, it's not necessary for 0.7, but I wanted the devs to know about it.

[Auria]

Hi,

as you said the view is a little boring, but the shape of the road is quite good, so keep up the good work

Now, regarding seeing part of the race on a billboard; I'm very dubious of this. The main problem is that it increases considerably the amount of rendering that needs to be done per frame, and this may be a bottle-neck for users with lower-end machines. Especially some cheap graphics cards and/or bad drivers are very slow at render-to-texture and this would be make the track basically unplayable for these people

[Pixel]

I actually had to modify the shape of the road in the tunnel attempting to get rid of a view problem. I happen to fix another problem I was having
along the way. I haven't yet tried the newest alpha release, that's something I'll have to do.

What about a live standings list? Would that work any better than rendering from a camera?

I agree that broad allowances should be made for different graphics cards. Not everyone has the latest ATI 5x/6x or nVIDIA GTX 480. I myself only have a
decent mid-range card. One can only go so far, however. From my experiences with the Intel GMA 3100 GPU, I don't think a game can be optimized enough for it.

I wonder, would there be a way to time an RTT operation, and disable it gracefully for cards where it's too slow?

As for other track work, I actually don't like the texture on the tunnels entrances/exits. I hope to replace that with a suitably licensed texture.