RageSpline - Create smooth 2D graphics inside Unity Editor - RELEASED

[MaDDoX]

I don't think it is unreasonable to tell folks if their files do not import in your tool then they should pre process it in Inkscape or Illustrator.

Definitely, they're what we could call industry standards (SVG is even the native format for Inkscape) and properly supporting both is already a very tiresome, trial-and-error task. My parser does support polybezier right now, I'm still considering the support of circles and ellipses, they're a touch less trivial than rects and in the end you can always "freeze" them in the source app to get beziers. Might keep this one for a later release, just as text-to-vector support which's in its own league of complexity.

You might want to consider starting a thread in the showcase for RageTools, so you could entertain more detailed discussion without taking away from the focus of the RageSpline

Of course, as much as it is intrisically related (especially in this beta API stage) and promotes the "host" product, as soon as I have a showcase video for Rage Tools I'll add my own topic. Meanwhile, as a short update today I've implemented the parsing of all SVG outline and fill style settings, both color and opacity, just as multiple paths importing, each as a children of the master object. Now adding support to proper layering of paths will be trivial. iByte should be happy to know that I've also found out what causes the "mesh ripping" problem he posted some pictures about. It's got to do with the overlapping of vertices in closed (loop) paths, plus the lack of proper miter limit adjustments. I've had to do some juggling to work it out - and curiously you still need to nudge any of the path vertices after the generation to properly "wake up" the miter outlines - , there's still the problem of "beak" vertices which will require angle reflection, I'll work on that tomorrow. Keely, apparently your RefreshMesh() isn't affecting the outline mesh? I know I could dig into your code to find out but tbh if I start doing that I'll never finish what I'm doing So, pictures, worth a thousand words (which I've already typed), yada yada:

[keely]

yada yada:

I'm sorry I got a little confused what were the bugs and what you already fixed.

Could you make list where you describe each problem and post picture or unitypackage (if possible) separately?

[MaDDoX]

I'm sorry I got a little confused what were the bugs and what you already fixed.

Okay, sorry if I spit it all out with minimal to no organization, I really thought the pictures would make it clear. Plan failed obviously So:

1 - "Ripped" meshes (the thing iByte was complaining about) - "Fixed". That's not truly RageSpline's fault, imo. iByte should tweak his adapted SVG parser to make sure there is no overlap between the end point and the starting one. Simply aligning the tangents orientations doesn't work, btw.

2 - "Beak" vertices (I don't know how else to call it, they do look like a bird's beak :P). One example is highlighted in the red triangular shape, second to bottom picture. The problem here is more involved. I've tried to describe it as I understand it in the attached picture.

3 - Corners not being properly updated. That's an issue with RageSpline, I've found. The pictures of the previous post should make it clear, as soon as the mesh is generated the corners are chiseled, "bevel-like", with very poor results. Once you make a simple nudge of any of the ragespline points it fixes itself. Changing the point density also "wakes up" the ragespline and fix things up. It's possible to make that happen programatically within the RageTools SVG Import, it's just very weird having to do so and hopefully not very hard to fix on your end.

3 - Corners. In vector illustration programs there are three possible corner settings, they're adjustable per path (and not per point). I've added a screenshot showing the result of these three settings, they're present in the SVG format and used by all major illustration packages, would be extremely good to have them in RageSpline as well.

So to make it 100% clear, I have touched 0% of your code, and don't really intend to do so. I do have one suggestion though, while/if you don't add proper path edge settings - to add a "corner density" option to the ragespline. Basically whenever the point isn't natural (I'm assuming natural means "smooth" in illustrator terms, ie. leveled in and out tangents) ragespline would automatically multiply the generated mesh density close to those points by a set factor. I remember you mentioned some of that was already being done, but tbh it's far from enough as it is and we really could use a customizable control (ie. x2, x3, x4) since some shapes need it far more than others.

PS.: Talk is getting *way* too technical here, maybe we should move it to e-mail to stop annoying the 99% of people that simply want pretty and smooth vectors inside Unity? If you agree, PM me your e-mail.

[ibyte]

1 - "Ripped" meshes (the thing iByte was complaining about) - "Fixed". That's not truly RageSpline's fault, imo. iByte should tweak his adapted SVG parser to make sure there is no overlap between the end point and the starting one. Simply aligning the tangents orientations doesn't work, btw.

I think i am having a duh moment here - which of my posts does this issue get mentioned? I recall fill problems which were the result of my bumping vertex counts way to high on thin objects and the corners (same as you describe in your #3 corners) i found nudging was required as well.

I think we are handling the first/end points differently with yours being more correct and mine taking a liberty or two (read .. assuming because it is a closed path, the start point and the end point will always be the same (in reality they don't have to be) so that the final "z command" does not really have any effect because of that This works with my sample file but is probably not going to cut it in the long run.

While I think it's important to adhere ot the SVG spec as much as possible, I think making RageSpine act like inkscape/illustrator etc might be a bit of overkill... having said that I would vote for as much flexibility as keely thinks can be done without making it too complicated to use.

my 2cents

iByte

[keely]

Goddamit! Just wrote a post two miles long and lost it due accidental mouseclick. Oh well. Round 2.

PS.: Talk is getting *way* too technical here, maybe we should move it to e-mail to stop annoying the 99% of people that simply want pretty and smooth vectors inside Unity? If you agree, PM me your e-mail.

Let's just keep it here. Someone might actually be reading these

Thanks a lot for the breakdown. Very helpful.

If I understand correctly, a lot of the problems could be solved by making a single option per sharp control point whether user wants that one key vertex "pointy" or "smooth" (which is current behavior).

Of course there could be more options and fidelity, like you explained in the pictures, but for now this "hack" could go a long way yes?

3 - Corners not being properly updated

Your vertex count should be multiple of the amount of control points you have. If you have 4 control points, the vertex count should be 4,8,12,16,20,... etc

The SetVertexCount() in the API actually forces this so you can throw any number at it and then do RefreshMesh().

edit: SetVertexCount() and "vertex count" naming in the inspector is a little confusing. It doesn't mean the actual count of vertices. It means how many times the spline is split into smaller parts.

[MaDDoX]

I think i am having a duh moment here - which of my posts does this issue get mentioned? I recall fill problems which were the result of my bumping vertex counts way to high on thin objects

Those are the pics I'm talking about. It seems unrelated but, unless I'm 100% dead wrong, it's actually got the same cause. Before I've changed the import routine mesh wouldn't "rip open" with lower vertex count settings, only when increasing it. After the fix I can crank it up as much as I want and the mesh never gets those weird gaps inside it.

I think making RageSpine act like inkscape/illustrator etc might be a bit of overkill... having said that I would vote for as much flexibility as keely thinks can be done without making it too complicated to use.

I honestly can't imagine how a single extra-toggle would make it more complicated. Sure, we will be able to make the outline in a vector illustration program and bring it over to RageSpline, and for some things that'll be the best approach, but fact remains that for varying width outlines RageSpline will be your best option. You might not be aware but Illustrator width tool has to be "traced" to a closed shape, Inkscape doesn't even has an option for that. That's why I say that for full interactivity of tweaking variable width outlines using RageSpline will be the easiest, most flexible approach. That's why I'm asking a couple minor improvements in this area, I definitely don't see ragespline adding smart guide snapping or any high end illustrator features - maybe Keely does, but imo *that* would be overkill

Goddamit! Just wrote a post two miles long and lost it due accidental mouseclick.

Whenever I forget typing long posts in notepad++ first, this happens to me

a lot of the problems could be solved by making a single option per sharp control point whether user wants that one key vertex "pointy" or "smooth" (which is current behavior).

Actually we don't need per-point control, not at all, it should be a per-spline setting, probably in the general block. Watch the picture below, for "natural" points the adjustment makes no difference whatsoever. In the kind of points where you need this control (technically they're called "cusps") there are only two really interesting options - smooth/round and miter (the "pointy" one). There's rarely a need for the miter limit entry, you can just ommit it and calculate it as infinite - ie. all cusp vertices as pointy.

As for smooth, the fact remains that the current logic is not making it truly smooth, and increasing the vertex count changes nothing. Apparently the illustration softwares build a true arc around the cusp, with the same width as the rest.

So, while we're at it, if you truly add a "smooth outline corners" toggle, why not make it also toggle on rounded caps for open lines ("free" as you call them)? Right now there's only the default option, which's called "butt" in the illustration apps. The third cap option ("square") it's also hardly used and unneeded. If you make that happen I promiss not boring you anymore about the outlines quality

Summing it up:
- smooth outline corner ON: free lines get rounded caps, cusp (non-natural) vertices get smooth joints.
- smooth outline corner OFF: free line caps get the current (butt) behavior, vertices get miter joints.

Oh, one really thing I've found out for the "non-refreshing" pointy edges problem: after you create a prefab with it - which you probably will want to make the imported SVG "static" and visible out of play mode - the problem fixes itself. Curious huh?

[ibyte]

Yeah re: prefab - I found the samething when I went to send keely a sample via prefab and poof the problem was gone

[keely]

Summing it up:
- smooth outline corner ON: free lines get rounded caps, cusp (non-natural) vertices get smooth joints.
- smooth outline corner OFF: free line caps get the current (butt) behavior, vertices get miter joints.

I think I can hack the miter joints easily, because there's no adding extra vertices, just moving that key vertex on the tip a little further away.

The smoother smooth joints would take a little more work. I'll try anyways.

I promiss not boring you anymore about the outlines quality

I guess you haven't done any inward sharp angles with outline yet (think inside of Pacmans mouth). That's when the shit really hits the fan.

Oh, one really thing I've found out for the "non-refreshing" pointy edges problem

Does the problem still exists after what I suggested on my earlier post?

[keely]

Has any of the beta testers currently holding v1.1 even noticed that there's a style-system to centralize control. Does it work? I'm sceptical. It's your duty to break it

[prime31]

@keely, I noticed it but haven't had a use for it. I'll try to tinker around with it today if I get an extra few mins.

[MaDDoX]

Has any of the beta testers currently holding v1.1 even noticed that there's a style-system to centralize control. Does it work? I'm sceptical. It's your duty to break it

Yeah, same as Prime31, saw it but didn't touch it yet. I've noticed there's style inheritance/grouping in SVG, but from what I've gathered they're not referential like yours, multiple styles end up being duplicated due to the creation/layering order. I'll double check it anyways, maybe there's some tag system I'm unaware of, that'd be great.

I think I can hack the miter joints easily, because there's no adding extra vertices, just moving that key vertex on the tip a little further away.

Exactly, apparently the miter algorithm "projects" the two last real outline points following their current directions, then find the intersection between those two projected lines.

Smooth joints apparently make a simple arc (semi-circle) connecting the two last (what I call) real outline points in the simplest way, ie. using the cusp point as the center of the radius. If you can get that extra geometry math to work it'd be nice if it would be affected by the 'vertex count' setting as well. Talking of which, since like you said "your vertex count should be multiple of the amount of control points you have. If you have 4 control points, the vertex count should be 4,8,12,16,20,... etc", shouldn't the "vertex count" actually be a "vertex density" setting and actually work as a multiplier? That'd probably be very easy to make and automatically iron out what will seem like a bug to most users (like it did to me and iByte )

[coolpowers]

Has any of the beta testers currently holding v1.1 even noticed that there's a style-system to centralize control. Does it work? I'm sceptical. It's your duty to break it

The style properties seem to propagate properly (that's a lot of props), but I can't seem to drag a style onto a RS object, I have to go into the RS properties and choose the new style myself.

Incidentally, in the 1.1 version you gave me there's a bug with textured outlines, the outline UVs aren't being setup properly (uvPos always stays 0). I dunno exactly what you intended to do, but sticking something like

uvPos += (1.0f / splits.Length);

within the main loop in GenerateOutlineVerts() gave me a pleasing effect.

[coolpowers]

Btw (not RageSpline-specific) - what settings for time, fps, and physics are you using in the RageCube browser test? It feels much smoother (and faster) than anything I can get without setting the timescale to 2 or something.

[keely]

The style properties seem to propagate properly (that's a lot of props), but I can't seem to drag a style onto a RS object, I have to go into the RS properties and choose the new style myself.

Weird. Have to check that one. There was a time when drag and drop worked.

Incidentally, in the 1.1 version you gave me there's a bug with textured outlines, the outline UVs aren't being setup properly (uvPos always stays 0). I dunno exactly what you intended to do, but sticking something like

uvPos += (1.0f / splits.Length);

within the main loop in GenerateOutlineVerts() gave me a pleasing effect.

Same thing. I had that done at one point, but I guess I removed some stuff by accident.

The RageSpline-class is really bloating and I'm a bit disorganized with my source control etc. Maybe I learn someday.

Thanks for this.

[keely]

Btw (not RageSpline-specific) - what settings for time, fps, and physics are you using in the RageCube browser test? It feels much smoother (and faster) than anything I can get without setting the timescale to 2 or something.

I'm pretty sure I changed both timescale and timestep to something else than default values, but not at home atm so have to check it up.

[megadouwe]

Hi there,

We have purchased the RageSpline plugin and installed it on one of our pc's. (Windows 7, with Unity 3.3.0f4)

When we add the package within Unity, all goes well. However, when we add a prefab in the design area, there are only dots visible. No texture is shown in the scene view. However, when we switch to game view, the object gets visible.

How can this be solved? Its a bit useless if we cant see wat we are drawing...

Note: Also tried it on a Mac, works perfect!!.

[keely]

Hi there,
How can this be solved? Its a bit useless if we cant see wat we are drawing...
Note: Also tried it on a Mac, works perfect!!.

If you open the example game RageCar. Does it work on both Windows/Mac?

[megadouwe]

If you open the example game RageCar. Does it work on both Windows/Mac?

Hi keely!

In fact, that problem has been solved... Someone disabled the default layer so nothing got visible in the scene... Sorry for this post.

However, we are trying to use ragespline to redraw our previous developed levels to find out if it may reduce the loading time of our game. The more points we are adding, the more corners there are getting visible. Can this be solved by changing values in the script??

Thnx

[keely]

Hi keely!
However, we are trying to use ragespline to redraw our previous developed levels to find out if it may reduce the loading time of our game. The more points we are adding, the more corners there are getting visible. Can this be solved by changing values in the script??
Thnx

I'm sorry you lost me there. You have to post some kind of picture or explain the problem in more precise manner.

[coolpowers]

I'm pretty sure I changed both timescale and timestep to something else than default values, but not at home atm so have to check it up.

If you ever get chance to look I'd be much obliged.