Sounds good, and I think this effect should be added, although it’s a pretty simplistic one, it’s very useful in games…
Chman
Here is a image DP posted earlier for all of you that are two laze to compile the code ( Like me). 
DP How about adding this contractor?
public ControlFrame(String name, positionVertices type, float lengthRadius)
It would make things simpiler.
hey dp, good work,
few comments:
might be better practice to have 2 modes for the control frame:
- crossed (star et. al.)
- volume (box, cylinder etc)
and then use a parameter to control the angle & number of vertices. so a for (float angle=0; angle<360; angle+=(360/parameter)) kind of thing. This would allow the application to control how smooth they want the trail cross-section.
an optimisation would be to only add vertices to the trail if the node has changed direction/orientation (otherwise simply update the last vertex).
a third option might be to have a billboard particle emitted at each point in the trail instead of connected lines. like smoke tracers. just an idea.
Ok, so, looking at the screenshot it seems that the effect work perfectly. But I think you should reduce the trail thickness…
Chman
DP, great effect I like it a lot. One thing we need to take care of is the object creation. There is a lot of junk being generated each frame. Causing the GC to kick in quite a bit. maintainPositions and buildTriMesh are being called each frame and creating a lot of objects. We need to reduce that.
Overall, the effect looks very good, and I wouldn’t mind using it for a game. Great job.
DP How about adding this contractor?
public ControlFrame(String name, positionVertices type, float lengthRadius)
It would make things simpiler.
I think this would make things alot more complicated to be honest with you badmi and the user has to create the vertices, create a control frame with those vertices, then create a LaserTrail with that control frame.
What you want can be done already btw, just create a Vector3f[] array with each 2 vertices representing a single trimesh and set the controlframe's "positionVertices" to it.
might be better practice to have 2 modes for the control frame:
1. crossed (star et. al.)
2. volume (box, cylinder etc)
I dont see the point in this to be honest. It only makes things more complicated in the future. I chose this path because say you have an arbitrary shape, like a PQTorus, you could create a trail thats just right for it, so it fits it snuggly round the edges. Thats the idea behind the design, everything is customisable.
an optimisation would be to only add vertices to the trail if the node has changed direction/orientation (otherwise simply update the last vertex).
I dont think that this is applicable as when the object stops, the trail should reduce in size....Press Space in the test...
Ok, so, looking at the screenshot it seems that the effect work perfectly. But I think you should reduce the trail thickness...
Thats customisable chman :)
lot. One thing we need to take care of is the object creation. There is a lot of junk being generated each frame. Causing the GC to kick in quite a bit
Il get right on it.
:D
Ive changed the source in my previous post to fix some bugs that I found ://, and fix the GC problem.
I have also spoofed the test up, you can now control the box!
The important bit now is, how is its performance now?
DP
Haven’t tested it, but it looks awsome! What’s the performance difference between using the different modes (star, cylinder…)?
What happens is that every two vertices, 1 trimesh is created. So a cylinder has the most vertices (16 vertices, 8 trimesh) and the box has 8 vertices ( hence 4 trimeshes ), and finally the star has 6 vertices (also hence, 3 trimeshes).
Those “modes” are very configurable, you dont need to use star all the time, you could create…a Heart Shape (for those you love 
) and have that as the trail. It doesn’t really matter. Those modes are just whats often used.
So all in all, it all depends on how good your graphics card is really 
Hope that helps.
Just thought of something:
a third option might be to have a billboard particle emitted at each point in the trail instead of connected lines. like smoke tracers. just an idea.
The particle system can emmit particles are the vertices of geometry. So create a trail, dont render it, instead, have the particle system emit particles at those vertices, and i think that is what you want...
DP
"DarkProphet" wrote:
I think this would make things alot more complicated to be honest with you badmi and the user has to create the vertices, create a control frame with those vertices, then create a LaserTrail with that control frame.
What you want can be done already btw, just create a Vector3f[] array with each 2 vertices representing a single trimesh and set the controlframe's "positionVertices" to it.
You can keep the other constructor just add the new one.
Quote:
might be better practice to have 2 modes for the control frame:
1. crossed (star et. al.)
2. volume (box, cylinder etc)
I dont see the point in this to be honest. It only makes things more complicated in the future. I chose this path because say you have an arbitrary shape, like a PQTorus, you could create a trail thats just right for it, so it fits it snuggly round the edges. Thats the idea behind the design, everything is customisable.
The reason is this: currently you have to choose if you want a cylinder or a box. What if the user has a powerful graphics card and wants a very large trail? a cylinder isn't going to be round enough. However, if they can say "i want a volume with 16 segments around" then all is well.
Using it in my game now:
It’s the cylinder one - looks really cool. The downside is that I lost ~ 100 fps 
I guess it would go much faster if using the star trail, but when I tried, it looked like only one of the quads where showing.
Ive found a fundemental flaw in the design of this. And that is LaserTrail MUST be attached to the rootNode or a Node with absolute coordinates.
Me and Mojo had a long chat yesterday and we both think that it would be best if I restructure the LaserTrail to operate on the LocalTranslation of the ControlFrame rather than the worldTranslation. And its not as easy as swapping the two
So its back to the drawing board…sorry ://
I will take all of your comments into consideration with the new design.
NB, nice screenshot per. You must have the detail level of that trail to be somewhere in the 100s…but the new design is performace aimed too, so you wont lose that much with the new design Per
Any updates on this DP? Or has it fallen to the wayside?
i have exams and been revising. Ive been droping by the forums here and there…It will definetly be finished by the end of january
Sorry for the long delay…
DP
This hasn't been touched in about a year. It had severed object creation problems back then, and DP never finished it. However, the starting code is there, if you need it bad enough you can work of what he has and improve it.
i have made a nice looking laser shot out of these with little bugs
it's not ported to actual jME but it should work i think
But as i saw there's some laser tut on the wiki i will look before
Has anyone looked any further into this since the problems were identified?
don't think so. dark prophet left the je development team long time ago. but one of those people making a space game (hehehe) should probably be able to provide an alternate solution.