Page 1 of 1

Zippers

PostPosted: 14 Jun 2010, 16:06
by Sentmoraap
Hi, I am trying to add zippers support, and now I get flying zippers:
Flying_zippers.png

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 ?

Re: Zippers

PostPosted: 14 Jun 2010, 17:43
by 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 :
Capture-Fenêtre sans nom-1.png

Re: Zippers

PostPosted: 15 Jun 2010, 15:48
by 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.

Re: Zippers

PostPosted: 15 Jun 2010, 21:22
by xapantu
(Maybe you should post on the ML ?)

Re: Zippers

PostPosted: 16 Jun 2010, 02:32
by 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

Re: Zippers

PostPosted: 16 Jun 2010, 06:36
by 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 :| )

Re: Zippers

PostPosted: 16 Jun 2010, 14:45
by Sentmoraap
hiker {l Wrote}: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.
hiker {l Wrote}: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.

Re: Zippers

PostPosted: 17 Jun 2010, 00:36
by hiker
acme_pjz {l Wrote}:
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

Re: Zippers

PostPosted: 18 Jun 2010, 08:26
by 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 ;) ...