Zippers

[Sentmoraap]

Hi, I am trying to add zippers support, and now I get flying zippers:

src/tracks/track.cpp, line 735:

{l Code}: {l Select All Code}

        else if(name=="zipper")
        {
            std::string full_path = file_manager->getDataDir()+"/models/zipper.b3d";
            scene::IMesh *mesh = irr_driver->getAnimatedMesh(full_path);
            m_all_meshes.push_back(mesh);
            scene::ISceneNode *scene_node = irr_driver->addOctTree(mesh);
            mesh->setHardwareMappingHint(scene::EHM_STATIC);
            core::vector3df xyz(0,0,0);
            node->getXYZ(&xyz);
            core::vector3df hpr(0,0,0);
            node->getHPR(&hpr);
            scene_node->setPosition(xyz);
            scene_node->setRotation(hpr);
            m_all_nodes.push_back(scene_node);
        }

Did someone see the problem in the code ?

[xapantu]

You should modify the track file, maybe the exporter is buggy, I don't know.
If I modifie the zipper position I can get this :

[Sentmoraap]

I modified the code to let the game compute the heignt and the rotation. I modified the scene.xml files of Canyon and Amazonian Journey.
But the zippers are not animted yet.

[xapantu]

(Maybe you should post on the ML ?)

[hiker]

Hi,

we have actually decided a while ago not to support zippers as separate objects (i.e. defined by empties of type zipper), but only as textures (see http://supertuxkart.sourceforge.net/Materials_xml) - draw the appropriate texture, give them the zipper property and you are done. The idea is that we don't want to restrict artists to use the same size and shape of zippers; and we also hope that this way the zippers can be better integrated into the track..

Also there is some performance penalty since each zipper as a separate objects adds another scene node atm, while a simple quad on the track with a zipper texture will be culled as part of the octree - nearly for free. The source code of stk is also simpler if we don't support special zippers.

So, the question is: is there a good reason to support zippers defined by empties (which we had in earlier versions) as opposed to add a quad yourself to the track, and mark the texture to have the zipper property?

Cheers,
Joerg

[acme_pjz]

while a simple quad on the track with a zipper texture will be culled as part of the octree - nearly for free.

Maybe you can draw a zipper without add it into the octree (I don't know the mechanism of Irrlicht, e.g. scene node ) And write some code to automatic update track's polygon to merge zipper in it (maybe the algorithm is too complicated )

[Sentmoraap]

The idea is that we don't want to restrict artists to use the same size and shape of zippers; and we also hope that this way the zippers can be better integrated into the track..

I didn't throught of it. I agree this is better to let the track authors use the zippers they want, is better than standard zipper for all tracks.

is there a good reason to support zippers defined by empties (which we had in earlier versions) as opposed to add a quad yourself to the track, and mark the texture to have the zipper property?

Now I don't think this is necessary.

[hiker]

while a simple quad on the track with a zipper texture will be culled as part of the octree - nearly for free.

Maybe you can draw a zipper without add it into the octree (I don't know the mechanism of Irrlicht, e.g. scene node ) And write some code to automatic update track's polygon to merge zipper in it (maybe the algorithm is too complicated )

Yes, we could merge the zipper object with the track, I am just more interested in reducing the programming effort and complexity (while not impacting artists too much). And I seriously believe that once people have started to use different zippers, tracks will become more interesting. Consider e.g. a ramp, which probably needs a zipper to make sure karts fly far enough. A single zipper won't do, and a series of zipper will look odd - one big zipper will look much better.

But as I've said: most important is to make it as easy as possible for artists to design interesting tracks - so if our current approach affects artists too much, we will certainly add an easier way back in.

Cheers,
Joerg

[acme_pjz]

Yes, we could merge the zipper object with the track, I am just more interested in reducing the programming effort and complexity

Maybe the merge code is just in track exporter ... and just call some features/algorithms in Blender ...