Ribbon implementation

[lukaspj]

This PR adds an implementation of Tim Newell's ribbon code, with a "ParticleEmitterNode-like" RibbonNode.

Since receiveing the code from Tim, the following changes has been made:

• Option for fixed texCoords has been added to prevent "floating" textures.
• Tilescale has been added to scale texCoords.
• Now uses RIBBON_NUM_FIELDS instead of constant values for key value arrays.
• Option for skipping an amount of emitted segments such that you can optimize the ribbons when necessary by emitting e.g. 50% of the original amount of segments, at the cost of less "smoothness".
• Now only update buffers when new segments are added (Optimization).
• Option for preventing texture stretching, such that textures always look uniformly sized.
• A number of fixes, like being able to have more than 2 key-values.

This video shows off most of the new "front-end" features.

[crabmusket]

I love you. But, it looks like the build failed with this error:

../../../../Engine/source/T3D/fx/ribbonNode.cpp: In member function ‘virtual void RibbonNode::advanceTime(F32)’:
../../../../Engine/source/T3D/fx/ribbonNode.cpp:199:49: error: no matching function for call to ‘Ribbon::addSegmentPoint(Point3F, MatrixF&)’
    mRibbon->addSegmentPoint(getPosition(), trans);

[lukaspj]

Huh, I compiled and ran it before PR'ing.. I'll have a look at it.

[crabmusket]

The build failed on Ubuntu, but I suspect that's just because that was the build that ran first. If you really can't reproduce it, maybe try compiling a dedicated server.

[lukaspj]

Btw don't know if you noticed it but it seems to compile now.

[crabmusket]

Yup! Just have other things to do for 3.6 :/

[crabmusket]

Ideally we'd like some documentation on this for it to be accepted: specifically, docs on each field in RibbonData and an example datablock in a console doc fragment. If you're too busy to do these, I'll take it on myself!

[lukaspj]

Sure thing I'll brew something up.

[crabmusket]

I ask because I'd like to get this in 3.6 as eye candy. It should be easy for us to review since it doesn't touch much existing stuff, just adds features.

[lukaspj]

I'll write doxygen documentaion for the Ribbon class, and I'll put up datablocks for ribbons with and without textures. Just give me a few days :)

[crabmusket]

Sweet, thanks!

[crabmusket]

Reviewed and it looks pretty good. Questions, though:

• Interpolation? Or should this be handled already?
• Example art does not belong in Empty, but thanks for the stuff in Full
• Need to add an entry to the editor GUI to allow these items to be created without opening the console

I'll make a PR to your repo with these changes, so they can be added to this PR without me having to open a new one.

[crabmusket]

Not getRenderTransform? Then the next line would have to use getRenderPosition.

[lukaspj]

Just implemented it as it is in ParticleEmitterNodes:

Torque3D/Engine/source/T3D/fx/particleEmitterNode.cpp

Lines 289 to 290 in 69838bd

	getTransform().mulV(emitAxis);
	getTransform().getColumn(3, &emitPoint);

Would need to change both in that case imo, though it doesn't really matter.

[crabmusket]

Fair point. I'm just thinking, for example, a ribbon attached to a node on an animating shape. We'd want it to use the render position to account for that animation, surely. It's probably even more important here than in particle emitter because the interpolation between ribbon segments is actually visible, whereas with particle emitter nodes is generally isn't.

[crabmusket]

Oh, now I see that some of those Empty additions are because of shaders that need to exist. Le sigh. Oh... and they're... specific to the new art? Is there any sort of generic ribbon shader that could be added? What's the minimum amount of script needed for ribbons to work? Please don't tell me I have to write a new shader for every type of ribbon I want?

[lukaspj]

What do you mean with interpolation?

The minimal amount of script would be all the "basic" ribbon stuff. It's the simplest ribbon there is (just a simple colored ribbon).

You have to write a shader for specific ribbons yes. But it's no big deal.. E.g. the basic ribbon shader renders a single color, but you can choose the color in the ribbon datablock.
Same goes for the texture ribbon.

I just thought that a simple uniformly colored ribbon and a textured ribbon would be the most common use-cases, so I decided to add both.

[jamesford42]

Random note: CustomMaterial rendering doesn't play nicely with others. Eg, does not get fogged, does not receive shadows, etc. Ideally this would use a regular Material to render, then you get all normal material features as well as playing nicely with others.

[crabmusket]

I realised that when I was asking about interpolation it was because I was playing around with ribbons in the editor like in your video, and the basic ribbon has some obvious kinks in the path - but I realised that's because the editor is just calling setTransform a bunch, rather than doing any interpolated motion, so the ribbon itself doesn't get a chance to interpolate and create segments in those intermediate positions.

I'm not the happiest that defining ribbons from scratch requires defining shaders, but ah well. So do lots of things in the engine. If that's the best solution then I'll have to swallow it. It sounds like it also allows ribbons to be more flexible.

Thanks for the heads-up @jamesford42. Why is CustomMaterial necessary in this case, and what would it take to get ribbons to use regular Materials?

[jamesford42]

The vertex shader and pixel shader are not actually doing anything custom at all. You can probably just swap in a regular material and it might work. Alternately if there is some setup work for materials I am forgetting about, DecalRoad would be a good reference class since it has transparency but uses regular materials (if i remember correctly).

[lukaspj]

I updated with editor integration and simplified scripts. Also removed some of the datablocks from the Empty template, such that Empty only has the simplest available Ribbon.

I couldn't make regular materials work, maybe someone else can step in on that one?

[crabmusket]

The new Empty scripts look good, but all those singleton names (datablocks, materials) should have capitalised first letters :P. I sent you a PR (lukaspj#1) with some code style changes to make the source look a bit more like the rest of Torque with more spacing and alignment, and removed the #define.

[crabmusket]

Whoops. I went to change the capitalisation of the names but then you merged. I also meant to change texRibbon to TexturedRibbon.

[lukaspj]

Ah I thought for some reason that you wanted to do it in a different PR...
Re-open the PR with added changes if you can, I'll try and fix it then.

Sincerely
Lukas Joergensen
WinterLeaf Entertainment L. L. C.

-----Oprindelig meddelelse-----
Fra: "Daniel Buckmaster" notifications@github.com
Sendt: ‎24-‎09-‎2014 00:17
Til: "GarageGames/Torque3D" Torque3D@noreply.github.com
Cc: "Lukas Joergensen" ljorgensen@winterleafentertainment.com
Emne: Re: [Torque3D] Ribbon implementation (#744)

Whoops. I went to change the capitalisation of the names but then you merged.
—
Reply to this email directly or view it on GitHub.=

[crabmusket]

I'll make a new one. lukaspj#2

[crabmusket]

For now, we will merge this using CustomMaterials and add a new issue to investigate whether we should try to modify shadergen so we can use regular mats.