Hello guys, I am not sure whether this is bug or not, but it definitely feels like an undesired behavior.
In following PG you can see that trail mesh starts at 0:0:0 which it should not because source mesh is at different location. After “one length of trail” it becomes ok, but first several frames look quite buggy at the first look.
What do you think about it ? Maybe I am missing something but it is workong well later on.
Thanx guys, this computeWorldMatrix thingy works but really it is not obvious that it needs to be done (for someone who is not Jedi Master). But ok, logically the sphere is 0.0.0 until next frame so my mistake as usually
But seemingly it doesnt work well with TransformNode as a genereator ? I am actually using TransformNode because I want just the trail - not really any visible generator - using transformNode it is still behaves as it did previously.
Hello Evgeni, thanx very much !! I hesitated to use “real” mesh because I was afraid of another DrawCall for nothing. I didnt expect that it could work with disabled mesh. Now it is all clear, I will use some small disabled cube mesh as a generator.
Interesting is that it actually worked with transformNode (except that artifact at the beginning).
That’s because the generator passed in the constructor is not used for a lot of thing in the TrailMesh code, only 2 times:
let meshCenter = Vector3.Zero();
if (this._generator._boundingInfo) {
meshCenter = this._generator._boundingInfo.boundingBox.centerWorld;
}
A TransformNode has no _boundingInfo property, so this code doesn’t retrieve meshCenter, but still the code does not crash (however, this is why there is an artifact when using a TransformNode in your PG - meshCenter == (0,0,0)).
and
let wm = this._generator.getWorldMatrix();
This does work for a TransformNode.
It would be quite easy to make it work with a TransformNode…