Motion trails moving twice as far as object

Hello again,
I have been having quite a few problems with motion trails recently, and this most recent one is that whenever I move the node the motion trail is parented to, the motion trail will move, but twice as far as it should, it is even the same for rotation. I think this may be an actual motion trail problem, because when I move forward (the source of the motion trail moving twice as fast as the model) and rotate, the motion trail rotates around the model but at an offset, as if only the vertices in the motion trail are moving twice as fast, and not the motion trail node. If anyone wants to see the code I am using, I can try to post it, but much of the motion and control stuff is embedded in a much larger program. Any ideas or suggestions would be awesome. Thanks in advance!

Hmm… Could you perhaps try to put together a small program that demonstrates the problem? Something with just a target node and a motion-trail, being moved in much the way that you move them?

Sorry for not seeing this for a bit, here is that program to replicate it.

from direct.showbase.ShowBase import ShowBase

from panda3d.core import *

from direct.motiontrail.MotionTrail import MotionTrail
class Main(ShowBase):
    def __init__(self):
        ShowBase.__init__(self)
        self.disable_mouse()
        self.ship = self.loader.loadModel("models/smiley")
        self.ship.reparentTo(self.render)
        self.camera.setPos(0, 15, 5)
        self.camera.lookAt(self.render)
        self.keyMap = {'left':False, 'right':False}
        self.accept('a', self.updateKeyMap, extraArgs=['left', True])
        self.accept('a-up', self.updateKeyMap, extraArgs=['left', False])
        self.accept('d', self.updateKeyMap, extraArgs=['right', True])
        self.accept('d-up', self.updateKeyMap, extraArgs=['right', False])
        self.setupMotionTrail()
        self.taskMgr.add(self.move)

    def updateKeyMap(self, key, value):
        self.keyMap[key] = value

    def move(self, task):
        if self.keyMap['left']:
            self.ship.setPos(self.ship.getPos()+(0.2, 0,0))
        if self.keyMap['right']:
            self.ship.setPos(self.ship.getPos()-(0.2, 0,0))
        return task.cont

    def setupMotionTrail(self):

        shipTrail = MotionTrail("shipTrail", self.ship)

        flame_colors = (
            Vec4(0, 0.0, 1.0, 1),
            Vec4(0, 0.2, 1.0, 1),
            Vec4(0, 0.7, 1.0, 1),
            Vec4(0.0, 0.0, 0.2, 1),
        )

        center = self.render.attach_new_node("center")
        around = center.attach_new_node("around")
        around.set_z(1)
        res = 8
        for i in range(res + 1):
            center.set_r((360 / res) * i)
            vertex_pos = around.get_pos(self.render)
            shipTrail.add_vertex(vertex_pos)

            start_color = flame_colors[i % len(flame_colors)] * 1.7
            end_color = Vec4(1, 1, 0, 1)
            shipTrail.set_vertex_color(i, start_color, end_color)
        shipTrail.update_vertices()

        shipTrail.register_motion_trail()

main = Main()
main.run()

Aah, that code helped a lot, thank you! :slight_smile:

And indeed, by comparing that with the “fireball” motion-trail sample, I believe that I’ve found the problem:

It seems that MotionTrails have a NodePath stored in a variable named “geom_node_path”. In the sample-program, this node was being reparented to “render”, while in your program this wasn’t being done.

And indeed, adding such a reparenting to your program seems to fix it.

Something like this:

shipTrail.register_motion_trail() # Included for location-reference
shipTrail.geom_node_path.reparentTo(render) # <-- The important part

(I’d guess that by default the node in question is reparented to the target-node that’s passed in as the second parameter to MotionTrail’s constructor.

As a result, the motion trail was being moved both by its own internal logic following the target, and by the movement of the target (as a result of being a child of the target). That is, it ends up being effectively moved twice as far as it ought.

Reparenting the node to “render” prevents the latter of those two effects, causing it to be moved appropriately.)

2 Likes

Thank you so much! yes, this fixed the problem in my original program. Just as a side question, will there be any documentation on motion trails in the future? I can’t seem to find any on here.

1 Like

Ah, I’m glad that it is indeed working! :slight_smile:

As to your question, that I don’t know, I’m afraid: I’m not an engine-dev.

But you could always file a request for such an addition on the documentation issue-system.

Or indeed–if you feel up to it–maybe offer such documentation via a pull request. (When looking at the page to which I linked above, “pull requests” are found in the next tab to the right within the menu-bar near the top.)

1 Like