1
\$\begingroup\$

I generate that kind of mesh during runtime to display the path to follow to a target (think at something like the path your GPS shows you when you are travelling):

enter image description here

I need to reduce the displayed path going from one end to the other to simulate the travel the player did. What can I do to achieve such effect?

I can think about vertex modifications at runtime directly from a Monobehaviour class, or a shader(?). Are there any other (smarter?) moves to do here? Is Vertex modification the wiser choice for that kind of case?

Thanks.

\$\endgroup\$
1
\$\begingroup\$

Option 1: Draw the mesh as per the current state from the initial player position to the current position. For this, create quads for all fully-traversed segments, and then determine which line segment the player is currently on, and how far (playerSegmentRatio=(0.0->1.0)) the player has travelled along the length of that segment. For that segment, draw using something like drawSegment(playerSegmentRatio) (whereas all the others would be drawn at their full length, i.e. drawSegment(1.0)).

Option 2: Use the stencil buffer to mask the object according to player's current position.

Option 3: Mask by modifying the UV co-ordinates on the end points, using a PNG texture that has just two pixels: one filled, one transparent. You might need to add more vertices to the segment the player is currently in, in order to control where the transparent part (the part that hasn't been travelled yet) begins and ends.

Personally, I think Option 1 is the easiest.

\$\endgroup\$
  • \$\begingroup\$ Thanks, Option 1 is what I did so far. It's definitely the easiest option, but is it the more relevant / optimized? I mean, I have no idea which one of these 3 methods will cost the most on, let's say, a smartphone or something being not a powerful computer. \$\endgroup\$ – lvictorino Apr 20 '16 at 15:53
  • 1
    \$\begingroup\$ @Ivictorino To my mind, stencil buffer is a per-fragment op, and so will cost more on mobiles which are fill-rate limited... I could be wrong! (others please chime in) Option 1 & 3 are not much different - 1 has to reupload the mesh, and so does 2... from my time writing GL engine code, it's likely that Unity likely just re-uploads the whole vertex buffer for Option 3, even if you're only changing the UVs. But it depends how Unity organises the vertex buffer data: If it uses separate buffers for every vertex attribute (pos vs. UV), 3 could be marginally faster since we only upload UV, not pos. \$\endgroup\$ – Engineer Apr 20 '16 at 15:57
  • \$\begingroup\$ I would say your best bet is to test / profile. I also have no idea just how much geometry you're looking at using? It may be a moot point if the vertex count is small enough. \$\endgroup\$ – Engineer Apr 20 '16 at 15:59
  • \$\begingroup\$ Thanks for your help! My geometries will depend on the actual path... It's based on a real map so it could be huge. \$\endgroup\$ – lvictorino Apr 20 '16 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.