Tracks for first irrlicht release

[Auria]

Varivar: Thank you very much I updated the track in SVN.
EDIT: we probably want to have the updated .blend, please

Horace: I think these new textures are great But, as always, before I can integrate anything, I need a license statement ^^

[Auria]

you mean render-to-texture? it has nothing to do with copying the frame buffer and isn't really slow. just like rendering a second camera view (but it can be in a much smaller resolution, render less details,...). it should be very doable even on older cards. don't know how good irrlicht's support for it is though.

RTT is generally not slow, but, sadly, a couple people reported that the kart selection screen is sluggish for them (and it uses RTT)

[horace]

Horace: I think these new textures are great But, as always, before I can integrate anything, I need a license statement ^^

the license is the same as for my tracks like canyon. is this enough or do i have to upload them with some textfile or something?

[Pixel]

you mean render-to-texture? it has nothing to do with copying the frame buffer and isn't really slow. just like rendering a second camera view (but it can be in a much smaller resolution, render less details,...). it should be very doable even on older cards. don't know how good irrlicht's support for it is though.

Oh, ok. I see the difference. I heard somewhere that Nintendo used a framebuffer copy in MK64. I'm not too deep on real-time 3D theory.
I should have known Irrlicht wouldn't have to rely on such a low-level solution.

Render-to-texture doesn't copy the frame buffer, instead it takes the same 3D data from the desired perspective and (after possibly some extra processing),
draws it on an object face, which is then drawn by the main renderer when the camera displays the object face. Is that right?

As for speed, I would think "recursion" is one thing that could slow it down. (i.e the RTT "camera" and main render camera are pointed at the same object.)
That's not the problem in the Kart Selection screen though.

[Varivar]

Varivar: Thank you very much I updated the track in SVN.
EDIT: we probably want to have the updated .blend, please

Of course you do. Here you are

[Auria]

Horace: I think these new textures are great But, as always, before I can integrate anything, I need a license statement ^^

the license is the same as for my tracks like canyon. is this enough or do i have to upload them with some textfile or something?

No, your agreement is fine
Thanks for the contribution, adding the files right now

[Auria]

Of course you do. Here you are

Thanks, commited
We'd still like the lossless png files though

[Auria]

As for speed, I would think "recursion" is one thing that could slow it down. (i.e the RTT "camera" and main render camera are pointed at the same object.)
That's not the problem in the Kart Selection screen though.

Sorry, I don't understand what you mean here

[Pixel]

As for speed, I would think "recursion" is one thing that could slow it down. (i.e the RTT "camera" and main render camera are pointed at the same object.)
That's not the problem in the Kart Selection screen though.

Sorry, I don't understand what you mean here

I think I have it wrong. My brain's not wanting to think right in 3D.

Okay, only one camera following the racer around the course. Render-to-texture places the camera's view on an object (a screen object near the track, for example). If the
camera ever points toward that screen object, it will have to draw on the screen a texture that includes the screen itself in the texture. Resulting in an effect similar to this-

Here's an image that demonstrates the principle. (Visual effect may be tricky on the eyes.)

Image Recursion


A 3D program could get stuck in a loop process where it constantly re-renders the screen object and the texture that is supposed to be on it.

[Auria]

No, as far as I know, it's just multiple cameras taking different shots of the same scene, so I don't think this can happen

[Auria]

Horace: do you still have the higher-res version of the canyon sky? I can't seem to find the original package since the old forums went down; and now that we can use jpeg, we can use much larger images without bloating STK as much as .rgb did Also, I know some people on IRC expressed interest in having your road textures in larger resolution, is 256x256 the largest you have?

[Varivar]

Unfortunately I don't have png files of the rock and the road, I drew those in Gimp and saved them in jpg format They didn't take that much time though. All other files are in this zip archive. It also contains a blend file of the rope texture. Btw, the difference between the jpg and the png texture aren't really visible to me.

[horace]

Also, I know some people on IRC expressed interest in having your road textures in larger resolution, is 256x256 the largest you have?

at first i tried to use 512x512 but this didn't really fit to the rest of the tracks (beach and lighthouse) since the other textures are quite low-res too. 256x256 did look better on those tracks in my opinion and now i don't have the 512x512 version anymore.

i have attached the bigger versions of my sky textures. the zip also contains a winter sky i made for a track i never finished. maybe someone else wants to use it?

[horace]

many edges in the canyon track are smooth shaded by mistake. this doesn't look right. it would be important that edges are hard/soft exactly like defined in blender. is this an issue with the exporter?

...and on the bridge it uses concrete.png instead of city_concrete.png. or was this an intentional change?

i also noticed that the small version of the textures gets used. in the zips of my tracks i have sent to auria when i made the tracks (but i don't know if/how they are stored in svn), there always were two texture folders, "small_textures" and "textures". for irrlicht i would use the "textures" version now.

[Auria]

many edges in the canyon track are smooth shaded by mistake. this doesn't look right. it would be important that edges are hard/soft exactly like defined in blender. is this an issue with the exporter?

I *think* the exporter should export the normals as they are in the .blend

...and on the bridge it uses concrete.png instead of city_concrete.png. or was this an intentional change?

I will let the track porter answer this one

i also noticed that the small version of the textures gets used. in the zips of my tracks i have sent to auria when i made the tracks (but i don't know if/how they are stored in svn), there always were two texture folders, "small_textures" and "textures". for irrlicht i would use the "textures" version now.

Very unfortunately, at the time the canyon track was added, I was making my first baby steps in STK, and did not yet realize the importance of keeping the original stuff As a result, I do not think I still have the original zip (since then, I have learned to immediately upload everything to the media repository) Hopefully someone still has them? :S

[Auria]

Also, I know some people on IRC expressed interest in having your road textures in larger resolution, is 256x256 the largest you have?

at first i tried to use 512x512 but this didn't really fit to the rest of the tracks (beach and lighthouse) since the other textures are quite low-res too. 256x256 did look better on those tracks in my opinion and now i don't have the 512x512 version anymore.

i have attached the bigger versions of my sky textures. the zip also contains a winter sky i made for a track i never finished. maybe someone else wants to use it?

Thanks very much, I added them all to the media repo so we never lose them I'm also sure the ice background will be very useful for our snow tracks

[Auria]

Unfortunately I don't have png files of the rock and the road, I drew those in Gimp and saved them in jpg format They didn't take that much time though. All other files are in this zip archive. It also contains a blend file of the rope texture. Btw, the difference between the jpg and the png texture aren't really visible to me.

Thanks
Even though the jpg may not seem much different, the idea is that if ever we want to modify them, it's usually best to modify the original png, then save to jpeg; if we modify the jpeg and save again, we double the compression artifacts

I will shortly add all those pngs to the media repo

[horace]

is it already possible to add physics objects to the track?

for example it would be cool if it were possible to crash through a brick wall for a shortcut.

or the vulcano could spew rocks. this would need some kind of adjustable emitter object. and maybe it would also require to delete the rocks again once there are too many (or at least once they fall into water or something?) so that it doesn't get too slow after a while.

[Auria]

is it already possible to add physics objects to the track?

Yes, but as long as they are animated in blender, or merely laying around and pushed by

for example it would be cool if it were possible to crash through a brick wall for a shortcut.

Maybe you could somehow pile up bricks and achieve the effect, but I'm not sure

or the vulcano could spew rocks. this would need some kind of adjustable emitter object. and maybe it would also require to delete the rocks again once there are too many (or at least once they fall into water or something?) so that it doesn't get too slow after a while.

Emitters are not implemented, AFAIK. IIRC Hiker played with this a while ago but it was never completed

[sj04736]

I've converted "Snow Mountain". Changes from the 0.6 version include animating the movement of the tux balloon, adding Horace's sky textures, and adding all of the collectables to the .blend file (they weren't there before)

[Varivar]

I've converted "Snow Mountain". Changes from the 0.6 version include animating the movement of the tux balloon, adding Horace's sky textures, and adding all of the collectables to the .blend file (they weren't there before)

Great work

is it already possible to add physics objects to the track?

for example it would be cool if it were possible to crash through a brick wall for a shortcut.

I think this is possible, but you will need a lot of movable objects for a brick wall, so maybe it will be to heavy to load.

or the vulcano could spew rocks. this would need some kind of adjustable emitter object. and maybe it would also require to delete the rocks again once there are too many (or at least once they fall into water or something?) so that it doesn't get too slow after a while.

I believe you can do this with animations as well. You can add several animated rocks to the scene. This way you will have more control over the rocks as well.

[horace]

yes, the snow mountain track looks nice!

I think this is possible, but you will need a lot of movable objects for a brick wall, so maybe it will be to heavy to load.

i only had about 20 big bricks in my mind. not a wall of very small bricks.

I believe you can do this with animations as well. You can add several animated rocks to the scene. This way you will have more control over the rocks as well.

i don't think mixing physics with animated objects works very well. the animated objects probably get seen as objects moved by infinite force by the physics engine. this can lead to all kinds of trouble like physics explosions or physics objects pushed through walls. at least this is my experience from working with other game engines...

[Auria]

i don't think mixing physics with animated objects works very well. the animated objects probably get seen as objects moved by infinite force by the physics engine. this can lead to all kinds of trouble like physics explosions or physics objects pushed through walls. at least this is my experience from working with other game engines...

you are quite correct here; when an object is animated, since the kart has no way to stop it, it can get thrown very far with extreme force

[Varivar]

i don't think mixing physics with animated objects works very well. the animated objects probably get seen as objects moved by infinite force by the physics engine. this can lead to all kinds of trouble like physics explosions or physics objects pushed through walls. at least this is my experience from working with other game engines...

You don't have to use both, it can be done with animations only. It will be harder to make it look realistic though.

[hiker]

No, as far as I know, it's just multiple cameras taking different shots of the same scene, so I don't think this can happen

This can't indeed happen. We create two rendered images (e.g. first the one to be displayed on the 'monitor'), then we render the picture on screen (with the previous rendered image).

Cheers,
Joerg