Smoothing a coordinate structure with javascript?

I've been meaning to make this kind of thing for you as you've hinted at needing it for a while now. I thought your 3D talking head comp was using such a patch until I realised you were using some other method. What other method was it btw? Is there a Kineme3D patch that can morph b/w two meshes of same number of vertexes? (I don't have K3D I keep meaning to buy it).

I'll give this some time early this week, conceptually it's straight forward. Plugin would be much faster and awesome-r I imagine but that's beyond my little coding fingers.

Can you attach an example of source data samples exactly how you would be needing them.

ie. set A and set B as CSV or XML or any other structured file. Not sure what the w co-ordinate does in the context of meshes either.

Also is linear interpolation sufficient, or are you requiring curve based smoothing. Curve based interpolation like the Smooth and Interpolation patches use requires me finding the equations some place… any ideas for where? I can do trig like sine function curve already ;)

Yeah, I'm going to continue working on it more until I "get it" myself, it's just eluding me.

What I used for that was the K3D 8 way GLSL accelerated mesh morph, which is technically an unsupported patch, but it has continued to work through all builds. The main caveat is that since it uses GLSL to enhance the morphing, you don't want to use it in a GLSL environment (though it doesn't really look bad if you do, fwiw). Franz posted a really nice example a long time ago, which is the only reason I even knew what it was supposed to do.

There is also a two way blend renderer that doesn't use GLSL.

Okay interesting. K3D way to go!

Mmm, yeah, maybe forget about x/y/z/w, they probably shouldn't be keyed, they can just be in order. I didn't really phrase that well.

Don't think of it as being file backed (though it could be).

Here is a tester, that also allows you to preview smoothing on the front end.

It would be really great to figure out how to do decreasing/increasing timing, and different curves would be the ultimate I guess.

(edit:reuploaded after a couple secs, missed one noodle connection...)

Ok I was thinking you wanted to 'wipe' from one set of points to another — which is easier for me because you just have to smoothstep (in GLSL jargon) from one value to another over a time range.

I did look at approximating the Smooth function once before with JS. I need to refresh on how it does what it does. If you can conceptual identify exactly what smooth patch does mathematically that would help. For instance in linear mode does it just clamp the increase/decrease value to the range set by the duration inputs? Some how this is going to involve getting the graph derivative and adding/subtracting by that I'm guessing. (mathemagicians feel free to instruct right about now!)

I made a comp to plot a graph of what the Smooth patch actual is doing it's a bit of a mystery just reading the output numbers.

Time for me to retire for tonight. Look at the comp and graph shapes and see if you can figure the equations, even in words will do and I can deduce formula.

SPACEBAR redraws the graph when you change curve inputs btw. Stop and Run gives a clean plot with correct start position.

Checkout the music visualizer for linear smooth in javascript ; no need to reinvent the wheel ( I thought I mentioned this in the initial post...). I just can't figure out how to manipulate that so that instead of smoothing a structure with a single value for each index, it smooths a structure like this.

It actually can be between two sets of points... but it would be better to just be able to have one structure input and have it "smooth" whenever the structure changes. That way one could just multiplex through many different models, get verts and normals, they get smoothed as the models get flipped, and then you rebuild it into a mesh using the mesh creator.

Sorry from the way you phrased it originally, I didn't realise the music visualiser comp was using JS to do it. Now I look at it I think that's were I've seen it done before!

This will take a bit of work, I can see why you're finding it tricky. Conceptually smoothing a 2D array is not much different to 1D. It's just that JS is a little tricking in setting up 2D Array objects compared to other languages where you can just declare them as 2D in one line of code.

With JS each sub-Array has to be declared inside each top level item (boring).

Add to that the fact the Javascript patch inside QC editor goes weird quite often. I find I have to paste the JS patch into a blank comp just to get it to work sometimes. I can't really find a 100% way to replicate the bug but I'm 100% sure it is there.

I find I frequently have to build the code from tiny basic steps and get each step to work before I enter some new code. That's what I'm doing now. Here's where I'm at which at least shows a 2D array being made. V basic I know and I've done a heap of times before but going stepwise (arhhh).

Try this. Man what a PITA JS in QC is!! I went a long way around to get this pretty simple mod of original Smooth patch in the Music Visualiser template.

Test it. I've noticed numbers are still approaching zero for long time after the rest have settled. Not a numerical problem (as it's delta is at 100+ dp) just means it keeps looping, which come to think of it, the patch does anyway. There's no shut-off so to speak. That applies to original patch too.

JS patch in Comp should work for any size arrays (at either level).

Note when you switch b/w to differently sized arrays you only get smoothing b/w the 'intersection' of the two arrays. To see this behaviour, change Dim1 and Dim2 inputs on the array creator JS patches.

And if you reduce an array size on the fly, this will not flush old values (guess I could add that pretty easily if required).

Just tried the smooth patch in your test comp and it works at first then bugs out and wont work again even with a QC restart. Feel free to help on the debug ;)

This seems to work pretty stably now. All I changed was some commented out text and it started working again — go figure?!

There's a trillion different dynamics to be had by modulating the smoothing scales. Nice vision gt. LFO modulation is as good a place to start as any ;)

You are right, usefuldesign.au when you observe both that the JS patch can [occasionally] go a bit skittish and also that this is deuced difficult to reproduce.

BTW the LFO example will just spool out because without the reset employed from the Macro Patch, I get :-

[12:12:38.713]   <QCJavaScript = 0x1AEE2E30 "JavaScript_8"> TypeError: Result of expression 'B' [undefined] is not an object.
[12:12:38.713]   <QCJavaScript = 0x1AEE2E30 "JavaScript_8"> Execution failed at time 1.999

Once the reset has been applied and the queue has been filled, these messages go away, but the LFO example needs that Macro Patch attached to work reliably IMETD.

Just a speculation , but I wonder which text editor you use when copying and pasting, as line end, text behaviour differences can result in the JS patch getting skittish.

I'm really starting to resent the JS patch. Not sure if it's the language or just this implementation. I could have written this patch in Basic, FORTRAN, whatever in a tenth of the time this took, just because of weird object handling anomalies, the undeclared pointer typing (which always makes me unsure what patch has done to a variable) and finally a lack of ways to debug save for manually making text variables for log statements.

The flake-out behaviour of the patch (thanks for the validation ;) ) is just icing on the cake — making what at times is a difficult situation impossible to get a read on.

I ended up overtly initialising the 2D Array rather than just testing for null objects and declaring new objects where required.

Quote:

I'm really starting to resent the JS patch.

LOL :-)

Know what you mean, usefuldesign.au, know what you mean.

BTW , [might be a matter of my lack of frequent visits to the same], but I've just noticed you've well revamped your website.

Lol, I wish all it involved was making a 2D array ;-)

Interesting! Cool... I also need to set that reset for it not to error out; interesting, b/c it's already in test mode. I'll look at it more and see if it works or if anything goes awry, thanks for giving it a go.

I wanted to start with this ( a smallish structure ), because throwing the structure of something like an entire 3D model might likely cause QC or the OS to stall, if the patch ended up being inefficient.

It's saying that the result of expression B isn't an object when it first runs, until it resets...hmm.

If after :

for (j =0; j <A.length; j++)

I put: if (B != null)

Then it won't spew errors if it happens to get run in "false" mode to start (but requires being set to non smooth and then back before it smooths). Hmm... maybe I'll try lopping that whole boolean setup out and see if that cleans it up. It seems close, I'll have to test it with some models, and get that debug message to go away...

I don't know if it really needs a reset because a smooth of 0 on everything would be roughly equivalent. One thing I note now is that this smooth gets more pronounced as the increasing/decreasing scales are reduced, which is sort of opposite of a smooth patch (though it may be this way in the music visualizer javascript... not really a big deal).

I just edit text in the Settings Inspector (Cmd-Sft-I) to edit code in. The parsing helps me with typing errors occasionally. What would you suggest for a JS editor/debugger? I've downloaded Coda and TextWrangler but haven't tried them much yet.

Dashcode looked good for 10 seconds then seems to complicated by the widget stuff to use it as a simple JS editor/debugger. Am I wrong?

Thanks for the console read out. I didn't realise the Console gives JS debugging info — yay! I know why the code is not working on the first run, like it says B is null first time through. I'll set up array to be initialised with the inputStructure values on first run.

Now I get this error in console: 5/07/10 9:26:54 PM Mail[1550] NSBundle </Users/alastairleith/Library/Mail/Bundles/ODMailBundle.mailbundle/Contents/PlugIns/ODMailBundle_10_5.bundle> (loaded) : Principal Class : ODMailCore105

Not even from QC but it's QC that is making the error for sure. I can't decode the message.

Smooth of zero could be a bit different to a Reset function (depending on how it's done). Reset actually clears the memory array (called "array"). Smoothing of zero just recalculates the numbers, so if the inputs structure size changes stuff can remain in memory array. If that makes sense.

I know what's going wrong (not having initial values to compare to), just having a time finding a way to fix it, as usual with JS the first, second and third ideas don't do it (it is what it is).

I wonder if that error results from opening and running a file in edit form the mail download cache folder?

cybero wrote:
BTW , [might be a matter of my lack of frequent visits to the same], but I've just noticed you've well revamped your website.

Actually I don't have a website. Been using Useful Design as my company name for nearly a decade and never bothered to buy the domain.

So now there is a Korean guy using it in aust and some pommie geeza too now! One day I'll learn WordPress and make a blog for QC and JS stuff (and my paid work ;) )

That's got to be it, well done. Why doesn't it get tagged as Quartz Composer error (like the one you posted) though?

Yeah, I know too... I was trying to get it to have initial values of 0, but it wasn't working for me. Thanks for the help though, you made it a little clearer to me how to perform calculations on structure in this kind of scenario ( I couldn't find one good example on this).

Wellllll.....

As promised, I'm posting a morph file.

Good news: This works WAY better than smoothing with the iterator/smooths/queue.

Bad news: At full structure count on a face morph model it gets around 2fps, when moving between the two models.

Good news: It can actually handle the whole structure and not make QC "beachball".

Bad news: There is something a little bit awry in the way that the model renders... a few polys/vertices look like they don't "decode" exactly correctly.

Good news: This is tantalizingly close, and the face is clearly rendered, save for the weird out on a few verts. If this kind of process could be accelerated via a plugin (or OpenCL? hmmm) and tightened up a little bit, we could be animating models from static poses, and rebuilding to mesh. So, my premise is sound, if it can be made to perform better.

Please see attachment... hopefully it runs enough on lower powered computers to at least see what's going on.

To me, even though this isn't exactly usable like this, it's a pretty frigging major step. I would love to see cwright/smokris/bmellen/vade/fsk/lov, (sorry for leaving anyone out!) etc take a look at this and see if they can lend a hand on getting the structure smoothing up to par, performance wise.

Point of origin of error comes first, the error breaks at the Mail bundle first [origin of file - an attachment] which gets reported first and as this is affecting an application outside of QC itself, it reports from there, just guessing though.

Just taken a closer look, it is totally to do with threading and messaging issues regarding ODMail, your online web mail service.

Scenario suggests itself to my mind is opening the attachment in your QC from the link in your browser or Mail client - seeing as how we are pointed to that folder, that then needs to call home, loses contact, flakes out. Not sure on what or where things fail for you, but it seems likely to be that.

Yeah OpenCL seemed like the QC HolyGRail when I first heard about it. Being Leopard I have no first hand experience. From what cwright has said, passing the data over the CPU->GPU bridge for every cycle can be the bottle neck (no idea if that's avoidable or not but the data has to come back to the QC graph unless you can port it somewhere on the GPU to a shader). I'm guessing a standard Cocca plugin would whip this baby into a cheater.

Thanks for posting the results on a mesh. I can see lots of uses for this with structures that aren't quite so big. Look forward to seeing the vimeo/you-tube!

How many verts do those models have, btw? (I can't run that comp, sorry I have lame hardware). I can see uses for this with smaller point/line structures, but you're way way ahead of me in QC terms, I'm still wanting to explore/learn CIFilter programming before I get to 3D and GLSL etc etc.

gtoledo3 wrote:
Good news: This works WAY better than smoothing with the iterator/smooths/queue.

gtoledo3 wrote:
Bad news: At full structure count on a face morph model it gets around 2fps, when moving between the two models.

gtoledo3 wrote:
Good news: It can actually handle the whole structure and not make QC "beachball".

gtoledo3 wrote:
Bad news: There is something a little bit awry in the way that the model renders... a few polys/vertices look like they don't "decode" exactly correctly.

gtoledo3 wrote:
To me, even though this isn't exactly usable like this, it's a pretty frigging major step. I would love to see cwright/smokris/bmellen/vade/fsk/lov, (sorry for leaving anyone out!) etc take a look at this and see if they can lend a hand on getting the structure smoothing up to par, performance wise.

We still need to sus out the other interpolation curves. Might post on the list for a mathematical answer, after I sort out this bug. The 'linear' method isn't exactly linear to me, it's a sliding-scale kind of division, the smaller the diff, the less the delta; bigger diff, more delta.

Thanks really interesting. I just realised I can open direct from mail with gt's comp as it happens. Usually I download to a 3rd party QC comp folder. Mail wasn't running when this occurred as it happens — not sure if that's relevant! Any how, back to debugging.

usefuldesign.au wrote:
Smooth of zero could be a bit different to a Reset function (depending on how it's done). Reset actually clears the memory array (called "array"). Smoothing of zero just recalculates the numbers, so if the inputs structure size changes stuff can remain in memory array. If that makes sense.

Actually smooth of zero does nothing in this code:
lastValue += increasingScale * (value - lastValue);
as  increasingScale is a multiply-by-zero.

Try throwing in a structure range somewhere, start at 10, and slowly start bumping it up as far as you can... you can at least see the movement, and likely start making out a face.

It has 5000 something, and it's not really that high quality at that...

Interestingly, the GLSL smoothstep() function isn't a smooth linear interpolation, but a cubic curve between two values. This is fine most of the time, but if you were to use it to, for example, plot a graph between a series of points, it would produce a 'shelf' or flat area centred on each point.

a|x

That's interesting tb... is that the function that's typically used when doing a facial morph and getting the weighting correct?

Did you see the comp I post up the top of this thread graphing the smooth patch, tb. You can clearly see the cubic & exponential shapes with the right duration values. I'm wondering how to express it mathematically, any ideas?

Slightly improved plotter comp attached:

A very interesting example, thanks for sharing.

BTW - like those line control experiments you've posted examples of to vimeo

So, this is a render, obviously accelerated by Quartz Crystal. My real fps is around 3... this is 15 and 2x AA (which actually doesn't look as good as the QC msaa... I could have gone 4x~6x to get equivalency).

So, usefuldesign.au, you can see what I mean about polys not quite rendering correctly. All the same, it pretty cool that this is basically possible... it might be a fun effect on low poly models, even if it isn't accurate, in a total non-realistic, non-facial morph scenario.

However, it would be even more awesome to keep smoothing (pun intended), this into a real system that could work with properly modeled objects. I feel like this is all on the CPU, and that it's still likely an inefficient approach as far as non-GPU accelerated approaches go. K3D deformers work way quick, even on the CPU.

I'm also uncertain about the whole poly misrender scenario, and exactly what causes that. If the model is plugged straight into a mesh render, it's "ok".

Let's get this going, so that we don't have to have the shame of collada morph animation with OFX in QC (good natured ribbing here), when Apple actually has a collada engine, lol... (but obviously sees no benefit in having animation? wtf).

OT stuff:

FWIW, some of those use Replicate In Space in addition to iterators, and combos of both. I think the Replicate In Space is an awesomely fun patch, as it's so QC-centric, and out there to me. It was one that was a total mystery to me when I started using QC.

That said, I wish it had a custom interpolation curve and repeat modes available, and that there was a way of setting initial scale as well as final scale (this probably makes no sense to people that only use it in passing). Thankfully, smokris's GL Structure Environment can handle many of those concerns, even if it doesn't have all of the funky built in parameters and user interaction of the Replicate In Space. Replicate In Space is more efficient than an iterator (and so is GL Structure Environment) in many instances; I can easily go up to 4000 repeats in some cases and not even have QC flinch, whereas making the same "curve" or whatever in an iterator would bring QC to its knees.

The major impasse to building objects out of smaller objects in QC (like these sphere snakes), is that there is no real way to texture them.

(...and speaking of Replicate patches, never has having certain private patches being private bummed me as much as in the case of Replicate In Time being private. It doesn't work anymore in SL, which totally screws up dozens of compositions of mine, and I'm sure it's the same for others. Not bug-reportable, unfortunately :-/ :-/ :-/ )

The movement is pretty okay, I think. Probably needs cubic or exponential curving just to give it that quick fluid feel in the middle of the morph.

I'm wondering if the poly thing is that it is getting the vert's out of order. Not a very technical guess, I know, just that whole time I was writing the JS, I was considering the implications of "for (i in B)" vs. for (i=0; i<B.length; i++). Might be nothing in this case, but where data has Keys as in "X", "Y", "Z" it probably means the data get's keyed or doesn't.

Anyway this initial state of null bug has me beat. I've even written a debug routine that proves the array is initiated but it still doesn't like it in the main routine.

Maybe we should try the Lua plugin. Lua is supposed to be fastest scripting lang going. How much harder than JS in QC can it be to learn a new scripting lang?

For that matter can Plugins be written in basic C, or is Obj C required? I'm thinking diving into Cocoa for this might even be easier than this debug! Maybe franz/cwright/smokris/vade/etc will come to the rescue. I'd like to be independent though ; )

Me too, but I've plodded on this one so much, that I recognize I need to learn something from someone that has covered this territory... or really, at least a good point in a direction to figure it out. This is something I've been messing with on the side for a long time now.

Yeah, the structure isn't exactly the same in that there are quotes on all of the values except the 4th in the structure before it hits the javascript and parenthesis on the indices (1,2,3,4), whereas afterwards, all of the structure indices have quotes and the values have no quotes.

Conceptually, I thought the javascript would be sweet if the performance was good, because it could all be done with stock patches.

I agree about other smoothing curves being a positive thing...oddly enough I use quadratic and sinusoidal for organic looks movement many times, and neither has been mentioned ;-)

The biggest plus is that it finally borders on being able to do SOMETHING useful and of consequence with the apple mesh ability. I'm not selling other uses short, I'm simply not aware of anyone using it other than highly abstract experiments, or simple viewing of Google3D Warehouse stuff.

I think you mean "for (j in A)"? Tried that and it didn't make a dif...

Ok, I decided that the misrendered polys were irritating me...

Plugging in the get vertices and get normals directly into the mesh creator reveals an even more heinous misrender. Surprisingly, the javascript actually hammers it into shape to look closer to normal for some bizarre reason. Note : When you plugin the mesh off the multiplexer directly into the mesh port, it all renders correctly.

So, the get mesh/get normals are actually not working in conjunction with a mesh creator to recreate a mesh properly. WHY AM I NOT SURPRISED??? Crap man. So close to doing SOMETHING useful.

Somewhere, somehow, QC is able to parse verts/normals correctly, when input is directly into the mesh port, just not with the get mesh properties/mesh create/render.

I swear, everytime I get close to doing something cool with the new built in patches for SL, it crumbles in some kind of obscure bug.

Lol Yeah that wasn't literal! I just meant a "for-in" loop iterates through the existing key values and will assign them (or increments from zero in the absence of keys). Whereas "for i; i<something.length; i++" will provide i as incrementing numbers (good for items in an array).

There's still a kind of blurry area for me here in that it seems variables declared as new Array() can still get keyed (all be it with a number). As we know sometimes that key number (in quotes "") will mismatch with the item number (in brackets () ). I try not to think about the grey areas with tis because they are everywhere.

Going to post on the list to see if bug can be found for me. It's weird I have it at the point where just typing a CR in the Javascript code is enough to jig the thing into action without any external Reset trickery.

All my attempts at duplicate initialisations, null testing, etc, etc just can't do it. Sometimes it's something really weird in JS like declaring a variable before the main function. Or shifting a 'result.something = whatever' statement down a brace. Tried all that too...

Yeah I've been hammering on it as well... the best I have got is for it to "not" go into debug if smoothing is on when rendering starts, but at that point it doesn't render - I have to still flick it off, then on.

I'm still slightly distressed that get normals/get vertices doesn't rebuild the mesh successfully in the first place. I'm going to file a bug on that later, and I would appreciate it if anyone else that cares about using mesh would as well.

Basically, the bug report would take and plug the collada straight into a mesh renderer and offset it to one side. Then you would take a get mesh properties, set it to get vertices, take another, set to get normals, plug both outputs into a mesh creator, and then to the mesh renderer- and show how it looks horribly broken (I actually touched on this before when cybero brought up the inconsistency between straight ahead rendering and breaking it up and then using the mesh creator, but in that case, there was nothing processing the normals/verts, so I was just like "don't do that, no point" lol. Ahhhh me.)

For anyone who wishes to file a duplicate, or isn't familiar with bug reporting...

Problem Report Title: QuartzComposer-GetMesh-MeshCreator Bug Product:Developer Tools Version/Build Number: 10.6.4(insert build here) Classification: Serious Bug Is It Reproducible?: Always

Summary: Using the Mesh Creator and Mesh Renderer does not produce the same visual result as connecting a Mesh Importer directly to a Mesh Renderer, when the source data is identical in both cases.

Steps to Reproduce:

1- Open Quartz Composer.app and create a blank composition. 2- Drag a .dae file onto the Quartz Composer Editor, creating a Mesh Importer patch. 3- Select a Mesh Renderer from the Patch Library. Place patch onto the QC Editor. 4- Connect the Mesh Importer output to the Mesh port on the Mesh Renderer. 5- Select a Mesh Creator from the Patch Library. Place patch onto the QC Editor. 6- Select two Get Mesh Properties Patches, place onto QC Editor. Set the Key of the first to Vertices, set the Key of the second to Normals, connect outputs to corresponding inputs of Mesh Creator. 7- Create another Mesh Renderer, and connect output of Mesh Creator to newly created Mesh Renderer. 8- Offset each Mesh Render in X value or Y value, so that one can clearly see them side by side. 9- If necessary, enclose Mesh Renderers in Lighting Environment macro, to clearly see point lighting on the objects. 10- Observe clearly broken facets on rendering chain that uses Get Mesh Properties/Mesh Creator. 11- Please reference attachment.

Expected Results:

I would expect that each rendering chain would yield the same results.

Actual Results:

Using Get Mesh Properties to obtain Normals and Vertices, then using Mesh Creator to combine the two, and finally render with a Mesh render, does not result in an accurate representation of a source model. It looks as though facets are broken, and not connected in the appropriate places.

In this scenario, no processing is being done on the vertices or normal info, so simply not using this type of chain is an option. However, if one wishes to do any kind of processing on the vertex or normal information, and then create a mesh, it becomes impossible to do so accurately if rendering is not faithful when no actual processing occurs.

Regression:

This always happens, regardless of source model.

Notes: Please reference attachment.

...and it's Bug ID# 8160216

I'm fairly certain this is a known bug :/ (don't be offended if it gets marked as a dup)

How do you find what is and is not a known bug?

I must admit that I find the bug reporter to only be allowing me to find my own bug reports and does not allow me to see anyone else's new or duplicate bugs. Probably not meant to.

BTW, I think you're right , I'm pretty sure this has been mentioned as being a bug and reported as such , at least by somebody or another on the development list.

You don't worry about it being a duplicate ;-) In fact, you HOPE it is, so that they're already working on it, and so that your duplicate adds some priority and weight to the problem.

Having it only show your own bugs protects confidentiality. People use OpenRadar to publicly report bugs. Cwright and smokris are both really good about that... I've reported many a bug, but am totally lazy about OpenRadar.

I think cwright's right, it's a known bug, but I guess it would be worth while my filing a bug, so thanks for the guidelines.

Am I alone in only being able to trace anyone else's bugs on Bug Reporter?

Just read your response above - and that answers my question.

No problem, I figured it must be, as I've actually noted it before, and I know others have mentioned it as well.

I'm really curious "what" it is that is causing it... if translations or normalization of values with one of the get properties is slightly off. Mesh rotations, scaling, and translation, have all changed since initial SL, and I wonder if one of the "get" settings needs to be adjusted internally to reflect that. I can't remember if it worked in the GM, or ever. I'm curious if there is some process that can be done to get it working...

... I swear, I'm going to be so peeved if I end up building OpenFrameworks just to animate a collada mesh like this in QC. It's kind of ridiculous! ;-) The sad part is that this is seriously not asking too much.

One negative is that dupes mean you don't know anything about it ever again -- you don't know if it's been addressed, or what the status is, or what discussion has taken place with the original (if any). you usually get a notification sometime after it's been addressed, but that's not always the case (I had lots of pre-apple bugs that were dupes that have been fixed, but am still awaiting my notification :)

Stuff about confidentially is dead-on

Yeah, I totally wouldn't want people seeing my bugs always, because that would indicate what I'm working on, or maybe some semi-proprietary method, which isn't always sound from a business perspective. Sad but true (enter Metallica riff). That said, I could certainly OpenRadar the vast majority of the time.

Good point about not knowing if something gets resolved. I wish that could be automated/fixed somehow; this may make me split hairs in the future to try to get unique bug id's. I think there may have been a couple of times when I likely could have done that. Further reason for people to use OpenRadar, to see if it truly is a duplicate or not.

cwright wrote:
One negative is that dupes mean you don't know anything about it ever again -- you don't know if it's been addressed, or what the status is, or what discussion has taken place with the original (if any).

I agree, that's a disincentive to participate in filing bugs particularly for those not on the bleeding edge.

Think this version is pretty clean for gtoledo's test case. Test it in other contexts (like 3D meshes) and please report back.

I'm going to try it in some other 10.5.8 scenarios where values are Keyed for the Kineme GL Structure Renderer patches — that's after I enter a much needed slow down on the QC front.

Thanks x10 to cwright who taught me the Log command — a debugging god-send that resolved this curly issue immediately.

For the record, the Queue wasn't filled up when the JS Smooth patch started recording the initial values. When it compared the ever larger inputStruct coming in to the previous there were some undefined values to compare (not!) against.

Faster, slimmer, dynamic.

Thanks to cwright for pointing out 'undeclared' is preferable to 'null' for testing if something exists. This enables the creation of 2nd level Arrays 'on-the-fly' — what I wanted all along. Say good-bye to initialisation routine.

Sweet, this one is working fine without any jiggering when it starts up.

I'm just reloading it with some settings that make that completely obvious.

Cool, bypass is like a sample and hold, more or less, and the reset is the instant "on/off" for smoothing. Very nice, thanks for your patience in this.

Even if the mesh stuff is sort of broken, I'm sure there are going to be many scenarios where it's really convenient to smooth a structure, when you can't really smooth it on "the front end", so to speak.

It kind of amazed me that this hasn't been broached before, but I guess there has never really been a need for that kind of structure utility (?).

It would actually be cool to have many more typical patch functions work for typical structure organizations. For instance, having range, rounding, math and maybe other patches that work on a structure level with plugin patches that could hopefully process structs quicker, in addition to this smooth thing and some timing curves, are some sort of obvious tools. What I mean by that is to do rounding or ranging on each value that is in the structure, performing the same math op on every value in a structure, conditionals, etc., and then outputting a structure that has is analogous, but with whatever the operation is applied to the values.

Nice one. So Reset still works but By-Pass is more of a freeze current values now!

What's totally insane is that, even though the javascript process doesn't make the collada render correctly, that it actually looks less broken than if there was no smoothing going on. Seriously... I'm attaching a picture, so you can see how screwed up SL is.

The one on the left is plugging mesh straight into mesh renderer.

The one on the right is "Getting" (ha) normals and vertices, then plugging outputs into corresponding inputs on a "Mesh Creator" (quotes are very deliberate in this message, lol), then into a Mesh Renderer. Witness the horror.

You know what it looks like with your javascript in-between from the render video. Messed up, but not scary messed up like this.

It's funny that the you're the one guy who really chomped into this and your still on Leopard! My kinda guy ;-)

Preview	Attachment	Size
	The Horror.png	113.24 KB

I've been think about that for a while in the context of the mythical 2D drawing Plugin (the Quartz 2D framework inside QC perhaps).

A series of creator patches that actually just generate pre-defined constants (to represent shapes, splines etc etc ) and setting values (to keep it all low-bandwidth until rendering stage) embedded in a flexible structure.

Then a set of modifier patches, kind of what you are suggesting but geared to work with these shapes as defined in specialised structures. For example a spread patch that input's shape or shapes and then replicates them over some range according to input port settings (say x and y values to make a path of diamonds in a circle path). Or a transform, scale, rotate and transform again to all shapes in structure. Or colour modulation on structure of shapes over this range of colours etc etc.

The Kineme particle tools which I never got into was the inspiration as much as anything, the way they talk to each other in a pre-determined but flexible way. Like Lego (in a word)!

Then you'd have you Rendering patches at the end of the chain taking the shape constants and values, stacking order, transparency and rendering it all to an image (RII like).

The big problem for all this is pre-defining all the conventions before the use scenarios all come along. As you said "It would actually be cool to have many more typical patch functions work for typical structure organizations." It's deciding what that typical structure is that becomes a stab in the dark.

I guess it would be fruitful to study nodebox, processing et al for models — I know you've been there, done that. How are spreads/structures handled in those apps?

gtoledo3 wrote:
The one on the left is plugging mesh straight into mesh renderer.

The one on the right is "Getting" (ha) normals and vertices, then plugging outputs into corresponding inputs on a "Mesh Creator" (quotes are very deliberate in this message, lol), then into a Mesh Renderer. Witness the horror.

I'll examine the structure ins and outs later this week to see if there's any shenanigans in the JS patch that could be messin with you're man's complexion. I pretty much doubt it as I checked the early grid thing for accuracy, who knows though, this is JS in QC after all?

Quote:
It's funny that the you're the one guy who really chomped into this and your still on Leopard! My kinda guy ;-)

Thanks for "The Horror"

Oh, the pic you're looking at doesn't even use your javascript; re-read my explanation, hopefully I was clear... it just shows the brokeness of what I'm starting to think is only the Get Normals function. Your javascript is more correct than that ;-)

However... I have found a workaround. I'm polishing it off, and I'll post, but it's totally stupid that one has to take the approach I am.

gtoledo3 wrote:
Oh, the pic you're looking at doesn't even use your javascript; re-read my explanation, hopefully I was clear... it just shows the brokeness of what I'm starting to think is only the Get Normals function. Your javascript is more correct than that ;-)

gtoledo3 wrote:
However... I have found a workaround. I'm polishing it off, and I'll post, but it's totally stupid that one has to take the approach I am.

Welcome to my world! I'm considering holding my breath… but I need rest more.

So I just checked out Text Wrangler app, Cybero. It looks pretty handy with programming language colouring, auto-commenting, encoding options and all that jazz.

So here are findings:

As previously indicated, "getting" the vertices and normals, and plugging them into a mesh creator fails to yield an accurate representation of a model, so using that method with the javascript was inevitably bound to fail as well.

Avoid Mesh Creator like the plague.

Here what needs to happen - vertices and normals need to be, err "gotten" using Get Mesh Properties. Then smoothing, or whatever needs to occur. Then, one needs to use Set Mesh Properties to rebuild the mesh, NOT a mesh creator.

One plugs in the source model into the mesh input on the Set Mesh Component. Then one plugs the corresponding manipulated structure into the Mesh Component input (the one that was obtained with the Get Mesh, and smoothed with javascript), makes sure the key is correct (eg, you're smoothing vertices, so choose vertices), then plugs in directly to a mesh renderer. This makes things render and look correct. If one wants to go the extra step, you can smooth normals too by introducing an extra Set Mesh Properties into the chain (but most targets are so close that it probably doesn't matter?).

I've observed both, and Lighting doesn't seem to look wrong if I don't smooth the normals between models.

The version I'm uploading smooths just Vertices, but has the extra chain with normals setup, so all one has to do is plug it in off of the second Set Mesh Properties (the unplugged one).

So, not only has structure smoothing been handled, but so has working around Apple MeshKit Ultra©.

3fps. Sigh. K3D handily outdoes this.

So, I just wanted to chime in -- this picture totally reminds me of failed kineme3D experiments (typically when the simplifier or the smoother had bugs). Brings back memories :)

Well, chime away. I would love your thoughts on more efficiently smoothing structures like this. I imagine what I'm attempting may be brain damaged in my "route", so please feel free to tell me so.

I remember the simplifier and smoother having bugs for sure... remember those frigging cool renders I did with it (the simplifier) bugging out, and you mentioned that you might be able to duplicate it as a feature? (I know you can't work on K3D anymore, simply alluding to the coolness of the glitch in that scenario.)

By the way ;-)...

If one avoids the Mesh Creator, and uses Set Mesh function instead, this is what you end up with :

Albeit at around 3fps realtime.

I really think that the concept of the Structure Environment (in GL Tools) is an interesting one for QC, conceptually, in that you can have this structure pipeline going into an input that then has an effect on objects inside, in the way it does. That does much of what you describe, and so does the iterator really... with the ability to publish out of an iterator in SL, it actually opens up a myriad of easy possibilities, it just doesn't work effectively (hence, this thread).

I'm not sure that handling of structures in the way I'm talking about overlaps with 2D Drawing, but it might. For instance, the range/round type of functions I talk about seem like they would be fairly easy, because they would just apply to any numeric value in a structure. If you plugged in a structure of images or strings into something that rounded to nearest integer, you would see a structure of a bunch of 1's, which is what would be expected (if an image or string is present it outputs a 1 typically).

Maybe it makes more sense to just apply calculations like that to numeric values, and leave other data types that may be in a structure untouched.

In the case of a model with x/y/z/? type coordinates, it would be amazing to be able to just "range" all x, y or z values, with minimums and maximums. One could have it look like an object totally flattens out on one side as maximums were manipulated. Performing conditional would allow only vertices within certain values to render, etc.

Handling structures in processing is sort of analogous to javascript. I haven't used Nodebox too much since it added the nodal interface, and I shied away from delving too much into Python since cwright has assured me is the_suck. (I also got a conspicuous silence from him when I forwarded him the nodebox 2.0 link). I've not used it for anything other than to do drawing/queue type stuff. For setting up that kind of thing, most languages aren't too different.

In VVVV, you have spreads, which isn't really that different than having a structure in QC, it's just the way it works after that. Any type port (color, image, value, etc) can accept a spread input (again, just a structure). Then, on the port it connects to, you can choose whether it "renders" the all instances of structure, one instance, or whatever. You do this by using a "Point" that you plug the spread into, and then the "Point" (patch, basically), goes to a Renderer. If you didn't plugin the spread into the point, you would just see one thing rendered. If you want to break out one of the pieces, or arbitrary pieces, of structure you use a GetSlice/SetSlice (hahahah).

That's pretty flexible actually, but I'm not sure that there is anything that can't be handled by QC, especially with the iterator out capability in SL (if performance didn't suck).

Load Mesh, Get Mesh, Smooth Structures, Set Mesh & Render Mesh / Vertices [Normals, etc] - really good example.

Minded me to look at if skipping the smoothing step would improve matters, which it only did in terms of fps tripled, but instead of achieving the pretty impressive transition between structures, it just loads in one structure after the other , like a structure slideshow.

What I did find that proved useful was to create a quick talking heads routine, the variation of which is easily achieved by switching between different Interpolation modes with varying duration / tension, of course an LFO could also be employed.

About the only thing missing by not using the Mesh Creator patch [with all its quirks] is the choice of render type. I find a partial workaround on this is to place the Mesh Renders into a Polygon Mode patch and set that to Points.

Is the script still smoothing appropriately if given a fixed time value ? If you give the Smooth script a fixed value the fps really starts to skyrocket to like 100 - 200 + fps :-)

The attached file should be saved into the morph3 folder so it can load the appropriate files [your animatable, winking head]

gtoledo3 wrote:
I really think that the concept of the Structure Environment (in GL Tools) is an interesting one for QC, conceptually, in that you can have this structure pipeline going into an input that then has an effect on objects inside, in the way it does.

Yes, well we've both asked for the Kineme GL Structure Renderer Variables patch. That would blow the game wide open, given the speed advantages over Iterator patch. Probably means a major extension of existing patch

gtoledo3 wrote:
I'm not sure that handling of structures in the way I'm talking about overlaps with 2D Drawing, but it might…

Overlap is only figurative, in the sense that they're all examples of patches that modulate values in structures by knowing something about the nature of the data inside the structure.

Quote:
Maybe it makes more sense to just apply calculations like that to numeric values, and leave other data types that may be in a structure untouched.

My next step is to do that to the 2D Smooth (JS) patch so it can handle non-numeric values and pass them thru. My structures have text also and are choking. Being XML derived they have text at top level. So where a JS structure says
n: "n" = {Structure} … {} instead of angle brackets

They say eg. 2: "item 2" ={Structure}  …    {} instead of angle brackets So that's next. Or I change the XML to be more standard.

Quote:
In the case of a model with x/y/z/? type coordinates, it would be amazing to be able to just "range" all x, y or z values, with minimums and maximums. One could have it look like an object totally flattens out on one side as maximums were manipulated. Performing conditional would allow only vertices within certain values to render, etc.

So some of this we can do already, with that example, sort struct by "X", then sub-range the output to get a slice of verts according to "X" position. Guess we are both thinking of ease of use to some extent. Plus things we can do without coding it all in JS which is possible just not fast enough for 3D meshes from what you've said.

With the 2D Quartz stuff, you could do it with JS structure passing them all over but what's missing is the end patch — the Renderer 2D Drawing Patch that takes the symbolic code and outputs it in Display-Script crispness and smoothness to an image node.

Quote:
That's pretty flexible actually, but I'm not sure that there is anything that can't be handled by QC, especially with the iterator out capability in SL (if performance didn't suck).

That's fantastic and worth all the effort! Thanks for posting. Love the 0:10-0:11 guesture, "what-chew-talk'n-about-man". All the verts look in place, yes?

Immediately I'm thinking, okay we need diff curves. Imagine when both eyes close (0:12) and you split vert struct into two structures one with neg "X" the other with pos "X" values. Left hand side goes to a linear smooth while RHS goes to a sine with a lower duration (or some duration sweep to delay the gesture a split second). Would look more convincing and a-symmetrical-natural-like.

Or splitting the top verts from below the eyes so the brow has a different pace of movement to the mouth. Assuming you can easily join the structures back together. How does it know which verts go with which btw?

I'm happy with that result. Buy yourself a MacPro with a $1k GPU (or two) and you're in the Stelarc business.

Check this out... it's wrong, but totally fun. It's kind of hard to get the right curves for smoothing totally different objects - I realize that when I was doing the stuff with the smoothing/iterator, I was using a quadratic curve quite a bit.

This would probably look cooler with a slower increasing smooth, and a texture dissolve, but I haven't really messed around with it much.

The idea of having different curves for different values is actually really interesting. That's one of those things that is totally "not done", but might actually be possible with QC... that's interesting, I can think of how to do that one. Hmm, I wish it was easier to control texturing with the mesh engine.

Basically, if someone wanted the positioning you're talking about, you would usually just make another morph target model, but I really like the thought process and concept. It would be neat to try.

One thing I've found is that as I've messed around with the structure of the models quite a bit by rendering different vertex ranges, that chopping out various value ranges usually will effect models how you would expect. All positive X values, for example, generally ARE on the "right side" 99% of the time (or maybe 100%?), given that one is looking at the model from the perspective it was actually modeled at.

Clever stuff, sounds like it takes a lot of careful sifting through member sets.

dp

Opened up the .dae files with Text Wraggler.

position count ("X", "Y", "Z"): 2871; normal count ("X", "Y", "Z"): 5532; map count ("U", "V"): 11064; triangles count: 1844

Seeing as these files are XML it would seem logical that the structures could be divided then modulated and finally reassembled programatically. Two models might be an easier method in some ways. Unfortunately I can't open see the parts of the SL comp that import the files to see what kind of structures get produced.

Absolutely right, usefuldesign.au :-).

Polygons and float arrays are what you would need to be processing , I think almost all else can be dispensed with.

I think QC takes care of the matrices for the overall scaling to cube.

Please find attached a helix converted into an xml file that holds only those values used, namely being those values actually in the file to begin with .

I totally would not start worrying about parsing the actual text file - there's little point. QC/SL gives you x/y/z/some other number that is always 1, type structures for all vertices and normals, using a patch called "get mesh properties". So there is little to be gained by reading the raw xml, if anything.

In addition, for this to work, unfortunately, we have found that a Set Mesh patch needs to be provided with the output from a Mesh Importer - even though just vertex and normal creator data should work, the Mesh Creator is a faulty patch. Since the Set Mesh requires the output of a mesh port as well, parsing from xml would yield no benefit, since one would still have to load via the Mesh Importer (you would just be doubling your importer count).

I don't think that position count could equal vertex count either, because you usually have the same amount of vertices as normals. So there would need to be some further prep of the file as well... AND you would also need to get the texture. Lots of functionality to replicate for little gain.

You're probably right, although it won't necessarily stop me from trying.

Way I think on this is, once i've got a working construct, I can sling any .xml from .dae and then extract only those key terms and ranges required [and manipulate them]. Bit like re-inventing the wheel in some ways I guess.

Point well taken about the need to use a Set Mesh Component.

By the way... you mentioned something about losing access to drawing modes by not using Mesh Creator. The mesh renderer itself has a wire mode in settings, and there is some other patch that displays points, so you still have access to either mode, just not in the same way.

Write me up to still not "getting it", because anyone could take a vertices or normals out and use regular structure range stuff on it, in an already robust and reliable way. I've never had great performance loading stuff like that from text file, if the structure is ultra large (walk away, make some coffee, come back a few minutes later... yay, the full structure for the model loaded!)

Yeah I wasn't meaning to parse the text file. I just meant there's a simple order to the data so splitting the data structure from the loader patch (which I gather you are doing anyway to just smooth the vertexes and not the rest).

EDIT: You're point of 'position' and 'normal' count not matching is taken. Not matching Triangles either so they're not face normals too.

So I guess I'm saying I wonder if the structure can be split horizontally (eg. "X" < .0) to modulate, say, just the LHS of model as well as splitting it vertically (vertexes, normals, map_uv, triangles) which I think you do already.

I guess I should drop this since I can't really see what you are doing…

I've been playing around with sorting structures in different ways (like x,y,z,!x etc) and multiplexing between them. I ran into a problem that the JS patch treats all the different sort orders the same as far as smoothing goes because, even thought the order changes, the item key in quotes (eg 0: "281": {Structure} ) doesn't change for each point.

Solved that with a Bake Sort Order (JS) patch and its working on simple example structures but not with my more advanced point fields like geodesic dome points. Here's the simple method with a 1D array. The baked patch is built into the smoother patch in this case.

It's just a way of having a counter variable incrementing (count++) separately from the looping variable (for i in Struct). You might think the two variables would be same but they are not hence the solution to the Classic Array-is-out-of-order.

I actually have two patches called Unscramble 2D Array (JS) and Bake Sort Order — 2D Array (JS) now to solve these kinds of problems, I'll post them in the Repository I think they'll be really useful as this kind of question repeatedly comes up about the JS patch outputting structures.

This file is a little different in both formatting and content to the head files. Interesting.

I was speaking of the Mesh Creator 4 choice drawing mode as it happens,

easily confusable out of context with the Wireframe mode,

see attached pics.

The Mesh Normals and Mesh Vertices gives some options, but it isn't the same as choosing between Line, Point or Triangle [or Volume for that matter, I'm looking forward to that getting fleshed out, I think it's got to be like the .vol formator something].

As for the overly large data sets, an interesting problem, possibly best addressed in OpenCL, I venture.

More to the point, isn't it a pity that these modes can't be directly switched upon that patch?

[I know interface design, etc... ;-)]

Preview	Attachment	Size
	MeshCreatorDrawingMode.png	26.46 KB
	MeshRendererModes.png	22.04 KB