Work on Sandtrack again

[antoine]

Thanks for pointing those out charlie.

[jymis]

Thank you Ludsky

I'm not ok for mummy. But I already have plan to add a sarcophagus somewhere, and not just for decoration. With that I have another surprise to make the track more liveful.

Sandtrack updated :



For now I've added barrelss but they float in the air. Someone has an idea of the problem ?


antoine, charlie, I'm sorry but this example doesn't help me. It's just the same as before.
We have to stop copying (reality and others). We can create by ourselves to really give the game an identity.
I assure you, I'll withdraw my first palm and I have a new idea which is more like what some of you want.

[asciimonster]

For now I've added barrels but they float in the air. Someone has an idea of the problem?

Two ways you can go about this:
1. Make the barrels static objects and position them in Blender such that they don't seem to float. (requires some trial and error)
2. Make the barrels movable objects using in the STK blender panel. This will make then vulnerable to artificial gravity. Beware that you set the dimensions in the panel correctly.
If you set the dimensions to high, the barrels seem to float. If you set them too low, the barrels will be partially in the floor.
Explanation: STK constructs a virtual object based on what you enter in the panel, NOT what you have drawn in Blender.

You use option 1 when karts will never hit the barrels (because that saves CPU). You use option 2 when you want karts to be able to crash into the barrels and have fun...
I hope I have made some sense.

[jymis]

Ah yes, I forgot to mention that I want them movable.

Unfortunately, unless I'm mistaken panel, I don't see wrong dimensions. :s

[Auria]

For the barrels, you should apply scale and rotation before exporting. Atm they have a scale of 0.54, they should have a scale of 1.0

Another potential issue is that they are intersecting with the ground. The physics engine will certainly not like having rigid bodies that intersect with each other

[hiker]

Hi,

sorry for the delay, I was just too busy with other stuff.

You actually found a bug in STK, which is causing the problems. I'll properly fixed it in a day or two. For now (and in order for your track to work with 0.8): just move the whole track up to be around 0 on the up axis (currently the track is at around -140). That should fix the issue.

And you should indeed apply scale, and change the shape to be a "cylinder" or "cylinderY" (another problem you uncovered - we should switch the up axis even for the names; it's indeed Z for blender, but in irrlicht it's Y. Not sure what we do about this, since we would have to fix most tracks to do that now).

Cheers,
Joerg

[hiker]

Properly fixed in r12461. The problem was an old and unused feature that would reset an object below -100 back to its start position. We used this in a version of the old volcano track to let stones roll down (which would then fall down and after some falling be reset, so that they could fall again).

I would still recommend to move the track higher, so that it is compatible with 0.8

Cheers,
Joerg

PS: This feature is still in the code if anyone wants to use it, but it needs to be explicitly enabled now (reset-when-below in the scene.xml file). It still needs to be added to the exporter. Let us now if you want to use it.

[jymis]

Oh my... This track is a big mess ! I have to move object one by one, separately.

I'll let you know if that works.

[Arthur]

What? Doesn't pressing A select all objects/meshes of an object?

[jymis]

Yes of course.
But when I selected all and I put zero in Z location in transform panel, only one move. :s
Or I'm doing wrong…

But it's okay, everythings is in place.
Obviously ship's animation has been distorted. I have to fix it.
And the barrel's problem is finally solved ! \o/

I send you the track once it's finished. (remember there are palmtrees and other surprises)

[fraang]

Yes of course.
But when I selected all and I put zero in Z location in transform panel, only one move. :s
Or I'm doing wrong…

You are doing well. Sadly this is a usability problem of Blender.

[S@f]

Hi everyone!

I test again the new Sandtrack, and I found a bug : -The palm trunk fly
But I have also found the way to fix it It was not a big bug.
The palmbody2.jpg and weaving.png texture was not in power of two. So I have resized the two files and put them in a zip file . Please don't forget this rule, for the old graphic cards it's important, moreover the aim of STK is to be playable on a wide range of computers (Even the old ones like the mine)

The track look very good, but personally I don't like the new textures for the palm trunk and leaf. It's too much flat... or like cell-shading.
I prefer something like this for the trunk :

Texture suggestion for palm trunk

It's just a quick test not a real texture.

[jymis]

It's been a while since I'm working on again. And textures you have noticed respect POT rule now, don't worry.
Thank you to consider it anyway.

Even if I have big problems with my computer these days, I'll send here a new version soon.

I can just tell you that it won't be the Egypt ruins anymore, but at the time of the Ancient Egypt. =)

[hiker]

The palmbody2.jpg and weaving.png texture was not in power of two. So I have resized the two files and put them in a zip file . Please don't forget this rule, for the old graphic cards it's important, moreover the aim of STK is to be playable on a wide range of computers (Even the old ones like the mine)

Just for the record: we actually do support old graphics card, since irrlicht will automatically resize textures to be a POT if the card doesn't support it - the problem is that your driver/card is not telling the truth - it tells irrlicht that it does support them, when it actually doesn't We've been cursing about this for some time.

But since we noticed this we try to avoid non-pot textures.

Cheers,
Joerg

[Funto]

Is there some warning or else in the console when a texture is not POT?
Actually it would even be better if the game crashed with a clear error message (on screen) saying that a texture (giving the filename) is not POT: that would force the artist to respect this rule.
Do you agree?

[hiker]

Is there some warning or else in the console when a texture is not POT?
Actually it would even be better if the game crashed with a clear error message (on screen) saying that a texture (giving the filename) is not POT: that would force the artist to respect this rule.
Do you agree?

We could do that, but only in artist debug mode. We certainly don't want a normal STK to crash just because an addon with a problem is loaded. Plus perhaps a flag that avoids the crash ... in case that we need to allow a non-pot texture for testing.

Cheers,
Joerg

[Funto]

I would do that even in non-artist debug mode, as artists do not necessarily know it exists (or they could just not use it all the time too). But maybe just a full-screen message in red with a Cancel button would be enough?
About addons, they are checked before acceptation right? But yeah, there is some work in checking all existing addons...
As a fallback STK could also resize the images in software to make them POT when needed...and maybe save the result when in artist debug mode, as a helper tool for textures?

[hiker]

I would do that even in non-artist debug mode, as artists do not necessarily know it exists (or they could just not use it all the time too). But maybe just a full-screen message in red with a Cancel button would be enough?

It's difficult - I certainly don't want a release version of STK to crash under these circumstances (since it should work anyway, see below), otherwise I'd say just use #ifdef DEBUG - but many artists would be using a release, so artists mode is the only option I can think of.

About addons, they are checked before acceptation right? But yeah, there is some work in checking all existing addons...
As a fallback STK could also resize the images in software to make them POT when needed...and maybe save the result when in artist debug mode, as a helper tool for textures?

Irrlicht actually does that - the problem appears to be that some graphics cards are just lying [Well, that's my assumption - irrlicht certainly checks if the OpenGL implementation supports non-pot, and if not, resizes every texture to be a pot. I don't have a card with that problem, typically it's PPC Macs iirc, so I can't verify that]

Cheers,
Joerg

[GunChleoc]

In the long run, I guess allowing only POT textures would be best. In the short run, maybe add a game option to the release version so users with buggy craphics can tell STK to always resize to POT?

[Arthur]

Well in the long run graphics cards and drivers should hopefully improve to the point they don't choke on such things or at least reports correctly what they are able to do.
But that might be a pipe dream...

[betharatux1]

looks like palm texture is better

[Funto]

It's difficult - I certainly don't want a release version of STK to crash under these circumstances (since it should work anyway, see below), otherwise I'd say just use #ifdef DEBUG - but many artists would be using a release, so artists mode is the only option I can think of.

You need to make sure the check is enabled when artists edit the game, and as there is no way you can be sure they use artist debug mode, you have to enable the check in all circumstances. I would go with the warning message box, so you don't take risks (the game still works), and you make sure all artists know what's going wrong. They won't want the users of their work to have this message, so they will fix the bug (the message should be clear enough though). The only "tricky" thing is the existing addons, that should all be checked and fixed first. After that, there is no reason a normal player will ever see this message. That's my opinion

Irrlicht actually does that - the problem appears to be that some graphics cards are just lying [Well, that's my assumption - irrlicht certainly checks if the OpenGL implementation supports non-pot, and if not, resizes every texture to be a pot. I don't have a card with that problem, typically it's PPC Macs iirc, so I can't verify that]

Yeah, Intel drivers :/ In any case, be it a modern GPU or not, POT textures always are a good idea, so I would adopt that as a design rule.

[hiker]

In the long run, I guess allowing only POT textures would be best. In the short run, maybe add a game option to the release version so users with buggy craphics can tell STK to always resize to POT?

Irrlicht actually does that - problem is that some graphics card are just lying, when queried they replay that they support non-pot

We could of course add a switch for that, and then make sure it gets re-integrated into irrlicht trunk.

Cheers,
Joerg

[Funto]

Sorry, I edited my last post - some messing up with the "quote" markup.

[Ludsky]

When this track on addons ?