Official SpriteShape Preview Package

I wonder if it might be easier to treat each as a separate object - the pulse of light and the textured shape. You could easily animate the pulse moving over the sprite shape and just use an overlay shader on it. If you used a mask on the textured shape as well it would do what you're looking to achieve without having to worry about the whole very specific custom shader thing.

 

just a thought , would it be possible to extrude spriteshape into a 3d mesh to create a 2d platformer with 3d assets ?

i really love the smoothness and flexibility of spriteshapes but seeing all these shiny new preview packages with amazing visuals comes out i really wish i could apply them to spriteshape

 

It would be really nice if there were more shortcuts when using SpriteShape.

Its strong suit is the ability to use custom shaders unlike Ferr2D which is limited in that way, but it's so much slower to build a level with SpriteShape than with Ferr2D. Please take a look at the asset Ferr2D if you don't know what I'm talking about.

There is also less artistic control when it comes to handling corners than Ferr2D too. Hope you guys try and implement some of these features in. Where can we see what you're planning to implement in SpriteShape?

Hiding the code away makes it really tough to change this tool and make it viable for an actual pipeline. I assume some of the code is optimized but please reveal it as much as possible.

When clicking on Edit Spline the camera goes to the center of the world, looks like a bug. Not sure why it's there but there's really no need to move the camera.

It would be nice to have a solution to the fact that the transform.position can be extremely offset compared to position of the splines points. I think making the first point be on the transform.position could be a solution. But that's something that can be coded.


Thanks for the tool, there's still work to be done!

 

Is it possible to make it an option to have edges and fills use different materials so they can be shaded differently? Or is that something that's already possible?

Also I forget if I already asked this, but would it be possible for it to take multiple different fill sprites and randomly use them to allow for more variability?

Also, I haven't tried the 2019.1 version, but would it be possible to make it so adding a new point doesn't change the adjacent points from mirrored to unlinked tangents? I never want to use unlinked tangents since mirrored tangents mode merges the adjacent edge meshes together nicely and unlinked doesn't. Either that or make it so with multiple nodes selected you can change their connect mode at the same time.

 

in my game sprite shape controller points,spline,spriteshape are change by scripts its work properly but edge collider is not updating automatically when i click on that gameobject then it is update. or when i change sprite shape controller values in inspector manually in editor then collider update.
but if don't click on that gameobject or not change value manually then its not update at run time.

 

I have created a world generation system that includes Sprite Shapes. This system progressively generates a rope bridge using the sprite shape tool.

This system works fine, but regardless of the changes made to the spline, the collider does not update. The collider is set to auto-update, and when I select the sprite shape in the inspector, the collider refreshes and works perfectly. I have tried all of the different functions available in the spriteshape controller, but none of them seems to update the edge collider.

The spriteshape is instantiated from a prefab, then the startPos and endPos are set. The game then calls updateSpline(), shown below.

 

Is it possible to offset the corners to align them with the rest of the border? (offsetting borders is not an option because they must align with specific sizes)

 

Hi, just a general question. Is it possible to make shape like letter T let say but with a constant outline? Ive tried 2d mesh maker but they seem to have inconsistent stroke. Thank you

 

That is my problem. The pivot of the sprites has no effect on corners, corner sprites are always centered on the spline points.

 

Ferr2D has the following features:
-Fast per-pixel and per-vertex 2D lighting shaders
-Separate physics materials for different edges
-Wavy shaders for grass, leaves, and other effects

Does your solution provide / will provide the same functionality? I think that lighting support is very important, as well as an ability to darken parts of level using custom drawn shape. I haven't seen such functionality in your blog posts.

 

Hopefully they're careful with how they handle edge colliders specifically. The Ferr2D 2.0 update completely changed how they created the edge colliders to a way that I did not want at all. Luckily I could turn off the edge colliders completely and still use the fill collider option to have the generated collider match the mesh spline's shape directly instead, but it made it so I could no longer have edges just being a single line edge collider. It forced me into using its algorithm that created a big complicated blocky edge collider monstrosity per edge, which does not fit my project at all.

Sure it has benefits of being able to set each edge to have its own physics material, (which I don't need, but is useful for some), but it was at a huge cost.

I'm only saying this because I hope if they do add more complicated colliders, they don't remove the basic "collider outline == spline outline" (which they don't quite have yet actually, maybe in 2019.1) functionality which I need because I need precision collider positioning that matches the spline exactly.

 

This might be a dumb question, but how do I get the Color component of the Sprite Shape Renderer to apply to non-Sprites-Default materials? I even tried a material using an exact copy of the Sprites-Default shader and it still won't work. It only seems to recognize Unity's built in Sprites-Default material.

Also, would it be possible to make it so you can set the current UVs of a spriteshape object to world space UVs without having to keep it on? Because if I'm trying to move sprite shape objects' transforms (for orthographic parallax effect) whose spriteshape profile has World Space UVs enabled, the fill doesn't move with the objects, which I don't want. But I need the benefits of two overlapping spriteshapes still having synced UV coordinates. An option that just sets the current UVs to worldspace once would be ideal.

 

Hi,

I was having a go with spriteshape. I was wondering if there is any way to change the z-point position?

Thanks
Pete

 

When will you add support for animating the spline points via the animation window and not just through code?

 

Hey, We've used SpriteShape for Rolando: Royal Edition (a remaster of our debut title, trailer below ).

Generally it's been great to work with, but wanted to raise a few points. This is with the 2018.3 version (not yet tried 2019.1 ver):

1. Bounds issues - when creating SpriteShapes dynamically with code it won't update the bounds until it has been rendered once (ie origin appears in a camera view), so if you are panning across to a shape that's never been rendered before, it will "pop" on when it renders for the first time as origin enters camera.

2. Can't set color dynamically with code

3. Can't set Z offset of edges (seems to be hard coded). We had to scale our objects in Z to provide this functionality

4. Garbage generation on OnWillRenderObject - "Cornersprite.equals" is generating a lot of garbage every frame. This is called from NeedUpdateSpriteArrays. We had to create a replacement to SpriteShapeController to prevent this per-frame garbage

5. Generation of mesh on OnWIllRenderObject is problematic as causes dropped frames on first render (as you pan across). Would prefer this to be on Awake/OnEnable

6. In terms of tools - the spline editing has the basics covered, but it would be great to have a more feature-rich toolset on top. Drawing primitives (square/circle), and boolean operations (combine, subtract, difference) would make level building so much quicker. We ended up using another package to generate the level geometry and writing an importer to bring the shapes in. Happy to go into this point in more detail if helpful.

But keep up the good work! Its a great package, excited to see it progress.

 

Hello, I'm back
Well, I'm glad the request about having colliders match corner height has been answered
...however, it's been a bit botched in the process, because now it treats Open Ended splines like Closed shapes



Those trees are weird, but point is, I use the colliders as triggers to define climbable areas, and as you can see it's now a mess :/

Also, in a not completely related topic, I noticed that the Spline and BezierUtility classes are in the U2D namespace and not the usual UnityEngine one, even though they support 3D. Why is that? People keep reinventing the wheel because they don't know they have a solid one right under their nose :/

 

Great work!
I'm really surprised to hear you used Sprite Mesh. The levels look 3D ...?!

 

How did you make the 3d shapes based on the sprite shape? Great work!

 

I just installed 2019.1 and the new spriteshape version seems to have some much needed convenience improvements.

I've mentioned all of these before, but it's been awhile and I figure it couldn't hurt to refresh them.
And if some of these have already been addressed but are not yet added to the current release I apologize.

1. It looks like there were some improvements made to collider generation, but they're still not enough for what my project requires. Though after investigating, I noticed that the collider does indeed match the fill mesh, but the fill mesh doesn't match the spline shape, which is what I need. Ferr2D is able to match the fill mesh to its spline shape exactly with adjustable detail and have its collider match as well, all while having a minimally complex PolygonCollider2D. Without the mesh+collider matching the shape, there's a big risk for areas of the collider being uncontrollably created in a way that would break my ray-based collision system hitting an unexpected collider angle that doesn't match the mesh. For example this is with settings:
High Quality + Optimize turned off + Offset = 0:


That's unusable for my project. There should only be 2 angles in the above picture yet the generated collider has 3, which would break my ray-based collision behaviour. However, this could very well be a bug because I tried setting the Offset to "0.00001" instead of 0 and it shapes to the corner much much closer the more 0s you add, and it seems like it should do that at offset = 0, so I'm 99% sure it's a bug. Another thing that might be a bug is I noticed that having edges affects the shape of the fill mesh somehow (and as a result the collider as well) , which I don't think is ideal (if I take the edges off the shape on the above picture, the fill mesh+collider matches the spline shape more closely, and adding an edge again slightly warps the fill mesh+collider again for some reason, so it could be a bug). If it's not a bug, I think it's a really bad idea that adding edges randomly changes the shape of the base fill mesh+collider functionality and it instead should be part of additional options, otherwise you get unexpected and uncontrollable behaviour.

Regardless, the collider (and as it turns out the fill mesh itself) currently trying to fit curves of the spline in general are not precise enough as seen here (ignoring the mesh bending texture failures which can be forgiven though if they can be improved that'd be great):


So if it's possible to add a slider of some kind that increases the complexity of the mesh to fit closer to the spline curve, that would be perfect and I would consider dropping Ferr2D immediately. Otherwise SpriteShape is still incredibly useful for non-terrain decorative objects, but for ray-based collision it's not usable at the moment unless you make incredibly basic shapes. Even then it's a risk since rays hitting an unexpected collider angle can completely break how they're intended to behave. Since many 2d platformers in unity potentially use ray-based collisions instead of rigidbody collision, I think it's important to address.

2. PPU is now per spriteshape controller instance which is great. But it still doesn't have an option to affect edges, which isn't great.

3. I noticed each Sprite Shape on screen still generates a non-trivial amount of garbage every frame.

Is this unavoidable or has that optimization not been made yet? I know at least some of it is editor-only, but I'm not sure if all of it is. I can't remember what was causing it. I think it's internally doing component checks for corner sprites instead of checking if corners have been updated, and if there are none it'll return null which creates garbage in editor only?

Longshot requests:
4. Snapping: Since the Unity Grid can't be adjusted, a way to snap to a factor of the Unity Grid positions, like maybe every 0.25x or 0.5x of the cell size in order to allow for more precise shapes. I need very precise collider angles and needing to use the Unity Grid is a big pain in the ass since the cell sizes are so large.
**(I looked into this in the source and the snap simply uses "InternalEditorBridge.GetSnapSettingMove()" for cell sizes, which defaults to 1. If I set the snap value to 0.25f or 0.5f instead of 1f it snaps to 0.25 and 0.5 the unity unit sizes respectively, which is very useful. But ideally there's a non-custom-hardcoded way to do it.)

5. An option for automatic corner generation for "straight point to point" mode. Your mirrored tangent mode does it very well in my experience. Is it not possible to do it for straight point to point mode except make the mesh sharper at the corner? Ferr2D does it very seamlessly. If the adjacent edges are the same, it warps the edge mesh into a very precise corner without needing to assign a separate image for the corner that probably wouldn't even match it as well anyway. It works at extremely sharp angles as well, whereas sprite shape corners have a very very limited range before they break or disappear, and they only even work if the adjacent points are also straight point to point which is incredibly limiting to the point where it's almost unusable except for very basic shapes like rectangles.

6. If you could make a one-time setting of a spriteshapecontroller instance to use world space UVs so they don't stay fixed to worldspace UVs in play-mode that'd be amazing. I mentioned it in an earlier post, but for orthographic parallax you need to move background elements' transforms and I need the benefits of overlapping spriteshapes having synced fill UVs, but not have it constantly update in playmode because when they parallax the fill doesn't move with the transforms. So maybe if you enable worldspace UVs and then disable it right after, it should stay where it was in worldspace instead of going back to what it was before would be the easiest solution, though I don't know any potential drawbacks.

7. My project is a 2D platformer that is very non-linear slope-centric. Ferr2D allows you to have more precise control of the curve of a point on the shape. So if I wanted a very symmetrical curve such as a perfect halfpipe slope like in Sonic the Hedgehog, it's just the click of a button. But currently in SpriteShape the curves are purely manually placed with no way to make them precise, unless I'm missing a feature somewhere. This is a huge detriment to my ability to create shapes I need for level design.

That's all I can think of for now. I still believe Sprite Shape has amazing potential. If you already know now if any of these requests can never or will never be implemented, let me know so I stop asking about them and can look for alternative solutions. But I'd really prefer if I could drop Ferr2D altogether since it doesn't look like it's being supported by the developer any longer.

SpriteShape is so incredibly lightweight and there's no way any 3rd party could make anything remotely as effective in terms of mesh generation without tons of overhead. Some complex Ferr2D objects for example can increase scene size by 300-500KB which is insane. But somehow SpriteShape can make an equally and infinitely more complex object and only use 3-8KB somehow. I have absolutely no idea how, but it's amazing, which is why I really want to be able to use this tool. Though to be honest if you could explain a bit how you can make infinitely complex shapes without increasing scene size I'm very curious. Where does the point/mesh data get stored if not in the scene? I looked through the source code but the SpriteShapeRenderer seems to be internal only and SpriteShapeGenerator.cs is basically Greek. I did mess with the kRenderQuality/kColliderQuality values in it and the closer they are to 0 the closer they get to the spline shape, but it still doesn't match well for certain curves. I'm not sure how Ferr2D manages to do it, because from what I understand poly2tri isn't as good as libtess (I have no idea what I'm talking about). Either way, how you made it so each spriteshape object stays under 10KB regardless of size or complexity is what I'm most curious about.

Anyway, If I could rank these in terms of importance for my project specifically it'd be maybe 1 >>> 5, 7 >> 6 > 4 > 3 > 2

 

Thanks! We use a depth rendering material on the sprite shape and generate extrusion meshes by sampling the spline. Very happy to share the extrusion script once we've upgraded to SpriteShape 2.0.0 it is broken with 2.0.0 now due to some changes). Unfortunately we've had a regression with the 2.0.0 release meaning you can't work with depth writing/testing materials any more.

 

We've just done a test upgrade to Unity 2019.1 and SpriteShape 2.0.0. Some of the changes and improvements look great but there are some new issues introduced that mean that we can't upgrade.

Case 1146739 - Unable to use the Depth buffer. We're using SpriteShape in a 3D scene to generate the front-face of meshes and rely on being able to use the depth buffer on SpriteShape materials (see our post above for Rolando: Royal Edition to show how this works for us). This is a regression of case #1079942 which had previously fixed this issue in 2018.3 by offsetting edges in Z. This Z offset appeared to be hardcoded though. Ideally we would be able to use a separate material for the body and for the edge, so that we can apply different effects on the edges (such as animation, glow etc).

Case 1146747 - As mentioned a few times above, there are a lot of GC allocations in OnWillRenderObject. I believe this is from "bool needUpdateSpriteArrays = NeedUpdateSpriteArrays();". Maybe something like "
bool needUpdateSpriteArrays = (Application.isPlaying) ? false : NeedUpdateSpriteArrays();" could help?

We're also getting a bunch of "Graphics buffers must be deleted on the main thread" - not sure if this is from SpriteShape?

 

I've also test upgraded the project. Unfortunately the new version is breaking the corners (straight line from point to point).

 

That's a shame! Hopefully it gets fixed! Would love to see that script some day!

 

I've been thinking about the material setup for SpriteShape and keep thinking how powerful a multi-material setup would be. The problem with having a single material for all edges/body is that you can't apply any individual effects (they have to be applied globally). It would be really nice to have selected effects on different edges and different from the body. For example:

• Having a grass sprite edge with wind simulation vertex shader
• Having glowing additive blend edges around a pinball table (animating additive multiplier)
• Having an edge which expands/contracts in the vertex shader

As each edge section is a separate draw call, would it be possible to specify an optional material override in the SpriteShapeProfile on a per-sprite basis (ie I could apply an animated grass material just to the grass, otherwise it applies the material for the SpriteShapeRenderer.

On the effect side, it would be great to be able to pass additional data to the shader in a second UV channel (eg distance along path, and from shape edge).

 

Hey,
we use Sprite Shapes in our Project. Since we updated to Sprite Shapes 2 the shape of our Sprite Shape resets when you press the play button. It is possible to "save" the shape by pressing the "update collider" bool once or twice, but that is obviously not possible if you don't have a collider on the Game Object (because its a Foreground for example). And I'm pretty sure it is not supposed to work like this.

Does anybody else experience this problem or knows a possible solution?

In addition to that, we also experience the problem of breaking corners like the comment #274.

 

Is there anyway to easily re-center the transform for a SpriteShape? After some dinking around with vertices, I often end up with something like this:


I would love a checkbox to auto-center or something along those lines.

 

Is there currently anyway to ensure the collider matches the geometry of the SpriteShapeController Spline? I currently get stuff like this:


This will not work for my project at all and kind of defeats the purpose of having a collider in the 1st place it seems.

For this, I have Collider: Detail=Hight, Optimize=Unchecked. Spline Detail=Low Quality (Similar issues whatever Spline Detail I choose.

Thanks!
-Jeff

 

Only for Unity 2019? Will there be a version for 2018.3? Now 2019.1 is still full of bugs, despite the "official release"..

 

Yo, I installed 2.0.0-preview.5 on Unity 2019.1 and the "Sprite Variant" does not work. I have two variations which would be sprite variations 0 and 1. It always renders variation 0 no matter what variations i set the nodes. I tried setting them all 1, individually, consecutively, nothing. Any thoughts?

 

I have a suspicion this is just a case of the collider not updating right away when I change some of the inspector values. I had this happen a few times since and was able to get it to map correctly by futzing with other collider related inspector values.

 

Oh also do you know how the color property on SpriteShapeRenderer works? If I use any other shader than the built-in Sprites-Default or Sprites-Diffuse, the color property doesn't change the color of the spriteshape. Even if I create an exact copy of the Sprites-Default shader and name it something else, it doesn't seem to affect it. Am I doing something wrong?

And would it be possible to expose SpriteShapeRenderer.cs as well just so we can take a closer look at how stuff is goin down?

And is it possible to make an option to pre-bake a static spriteshape so it doesn't get generated when it's first rendered at runtime?

 

I would very much like see a better solution for this as well. My game is using a very contrasting solid shape graphic style and the spite shape edge solution and the way it makes the corners invisible at certain angles just doesn't work for me.

 

I'm using sprite shape to make very high contrast solid-color vector style shapes.

Currently, I'm doing this by using only a fill texture on my Profile (no edge textures at all).

For example, the snow you see in the image below is just a sprite shape with a solid white fill texture.



My question: What is he best way to minimize the amount of aliasing when using just a fill texture.

The fill texture used above is a 512X512 white square with the following settings.


I know I can bump up the Anti Aliasing in the Quality settings (The image above is using 2X) but I'd prefer to smooth things out as much as I can without bumping this up to 8X.

Are there any other tricks/settings I can use to get sharp, non-jaggy edges using sprite shape?

-Jeff

 

My face after dealing with SpriteShape corners -

First, I don't have much experience with SpriteShape, just a test project where I'm toying with from time to time to see where things are so far. And IMO SpriteShape is still rough around the edges (pun intended )

In the last version (preview.5 - 2.0.0) all the corner sprites completely disappeared. But even before they were "unreliable". They were (dis)appearing based on angles and I could not find any way to reposition/offset them (for example based on the sprite's pivot point).

BTW there is some problem with collider corners in the last version (preview.5 - 2.0.0). Adjusting collider offset makes it easier to see.

 

I've actually run into the same issue in the new spriteshape. Changing the edge variant on individual nodes doesn't seem to change them sometimes unless I select multiple nodes and switch all of their sprite variants. I can include a sample project with this post.

I'd like to also mention a couple other things about the colliders. I prematurely spoke about the collider generation in prior posts before fully investigating how spriteshape is actually generating them. After looking at the code, it turns out the collider generation is actually identical to the generated fill mesh, which is exactly what I need. The problem is that it turns out it's the generated mesh that is the one that isn't accurate to the spline, which is what I really need. If that can be done, then the collider will then match exactly as well.


You can see in this image that the mesh deviates pretty far from the spline. I'm zoomed in relatively far but the difference is still very large for my specific needs. A sliding option for the mesh to be more accurate to the spline would be the perfect solution if possible. Since I use raycasts for all my collisions and they're incredibly angle-specific. If rays hit a single unexpected angle everything goes to hell. So if the mesh (and collider as a result) don't match the spline I'm shaping exactly, I don't have complete control over the collider angles, which makes it unusable for terrain for my project.

I did try messing with kRenderQuality in SpriteShapeGenerator.cs and the closer it gets to 0 the closer it matches the spline, but even still not accurately enough even at 0.

I'd also like to point out a bug with the collider generation as well that you can mess with in the project I'm including. I'm not sure if it's a new bug with 2019.1 or not, but adding edges changes how the collider fits the fill mesh for some reason.

I tried looking at the code to see why it was happening but couldn't figure it out. As you can tell the offset = 0 behavior doesn't seem right. Offset = 0 should be producing the same as both no edge as well as an offset of 0.000001. And adding an edge shouldn't change the shape of the collider at all anyway. So it's a bit of a mystery.

Attached is the sample project with just a single spriteshape with a solid edge and an invisible edge showcasing the issues. Requires zooming in pretty far to see certain things.

 

Here you go! The top one has a few variations changed from 0 to 1, but all render as if 0.
Second one, all but one of them are 1, yet all render as if 0.

Please confirm the bug is reproducible. I can't for the life of me make it show "1".

 

Would be very convenient if you just added a "Perfect Quality" for those that need it.

 

I had taken a look at those colliders before I made my post and without sounding rude, unless I'm misusing them they don't seem to do anything particularly better or worse than the current iteration of collider generation. At least for my needs.

I think to put it the most bluntly, for my project until both the mesh and collider match exactly the visual shape outline that I'm creating, I can't use it for terrain. Ferr2D has an adjustable quality setting for its curves (which it calls "Split Distance") that let you control the subdivisions of the outline to increase or lower the quality of the mesh curves. And the outline, mesh, and collider all match each other exactly so you have complete control over what is generated.

I do understand now though that SpriteShape is generated at runtime rather than pregenerated and mesh data saved to the scene asset, which explains why it doesn't increase scene size by more than 5KB regardless of complexity. Whereas Ferr2D is pregenerated with mesh data saved to the scene asset which can increase scene size by potentially 100s of KB depending on complexity. Each option have their own benefits.

Since spriteshape is generated at runtime, I assume one of your fears of allowing a perfect quality complex mesh is it being too heavy for runtime generation. So if you do make an option to create a perfect quality mesh, it might need an option to allow for pregeneration of the SpriteShape and store the data in the scene.

If I'm wrong about anything above let me know so I don't make arguments based on wrong information.

Ultimately I just need the mesh and collider to fit the spline outline I'm creating with a subdivision slider from 4 to 40 for all of the above so everything matches so I have complete control over what is being generated and there are no discrepancies. Until then, Ferr2D for terrain and SpriteShape for decorations/non-terrain foreground is the ideal mix.

 

Yeah this does the same thing as setting kRenderQuality directly in SpriteShapeGenerator.cs that I had mentioned in my last post, but as seen below it still isn't accurate to the editor spline in many cases.

I wish I was smart enough to help more, but it's way out of my league so I feel bad that all I can really do is sit here and point things out.

Below is what Ferr2D can do, and the collider is surprisingly incredibly optimized despite the curve complexity. And since the collider I believe is generated the same way as the mesh, I think the mesh is very optimized as well.


If I think I understand the difference, which I probably don't, it's because Ferr2D uses the poly2tri algorithm for its shape generation and spriteshape uses libtessdotnet and clipper? I don't really know exactly what I'm saying so I probably shouldn't have even said it, but from what I gather both have their advantages and disadvantages. For example with Ferr2D's algorithm the mesh fails generation if any points overlap the mesh, whereas SpriteShape's algorithm you can overlap any point over any part of the mesh and the mesh will still be generated as you'd expect it to. Among other differences.

If it comes across like I'm just trying to showcase how good Ferr2D is, I want to emphasize again that I want nothing more than to be able to drop Ferr2D completely and solely use spriteshape.

 

Just doing my job and a little selfish interest, heh.
I really would like if you could expose the ShapePoints with a get and set. What I do in my game is define some road section splines, then at runtime procedurally generate a long road using the segments.

I have to manually build a List of ShapePoint, set their properties from segment points via a stack of calls:

Code (CSharp):

1.  
2. ShapeControlPoint newPoint = new ShapeControlPoint();
3.              
4. //Position;
5. Vector3 childPositionRelative   = childSpline.GetPosition( childPointIndex );
6. Vector3 childPositionNormalized = childPositionRelative - childPositionOffset;
7.  
8. Vector3 relativeParentPosition = parentPositionLast + childPositionNormalized;
9.  
10. newPoint.position = relativeParentPosition;
11.  
12. //Mode & angles;
13. newPoint.mode = childSpline.GetTangentMode( childPointIndex );
14. newPoint.leftTangent = childSpline.GetLeftTangent( childPointIndex );
15. newPoint.rightTangent = childSpline.GetRightTangent( childPointIndex );
16.  
17. //Sprite index;
18. newPoint.spriteIndex = childSpline.GetSpriteIndex( childPointIndex );
19.  
20. result.Add( newPoint );
21.  

Then make a long road spline, and then set each point via anoter set of calls....

Code (CSharp):

1.  
2. Spline spline = spriteShapeController.spline;
3.  
4. int spriteIndex = 0;
5.  
6. spline.Clear();
7. foreach( ShapeControlPoint trackPoint in trackPoints )
8. {
9.    spline.InsertPointAt( spriteIndex, trackPoint.position );
10.  
11.    //This must be first;
12.    spline.SetTangentMode( spriteIndex, trackPoint.mode );
13.  
14.    spline.SetHeight( spriteIndex, trackPoint.height );
15.    spline.SetSpriteIndex( spriteIndex, trackPoint.spriteIndex );
16.  
17.    spline.SetLeftTangent( spriteIndex, trackPoint.leftTangent );
18.    spline.SetRightTangent( spriteIndex, trackPoint.rightTangent );
19.  
20.    spline.SetCorner( spriteIndex, trackPoint.corner );
21.  
22.    spriteIndex++;
23. }
24.  

It would be much simpler if I can just GET the list of points from the segments, concat them to "result", then SET the result List to the long road and be done...

 

Hi, I encountered a very strange bug with spriteshapes, and here is my report:
(If this is not the place to report bugs, please direct me to the correct location)

For some reason whenever I build the game, the spriteshape does not show up, but it shows up fine when playing in the editor.
I'm using Unity 2018.3.14f1 on Windows 10.
The build and project source code is available here: https://1drv.ms/f/s!AolZNQSwCdfsnmgCV4Yiks1D8VcT

 

Whatever changes you've made in the most recent update are fantastic. Incredibly impressive how you managed to improve it so quickly.