|
|
Mesh Vertices Display - Was It Fixed Yet? Does the mesh vertices display patch have an input for "mesh" on people's systems? I think that somewhere along the way that patch was broken and the mesh input was unpublished (it's a virtual patch). I remember modding one of those patches so it would work again (either mesh vertices or normals display), but now I don't know if people have systems that will work if I use it in a composition, basically. ( I guess if I've changed it, that it will give prompt update the macro, when it opens on other people's systems, if this hasn't been fixed?)
|
seems to display fine for me in xcode (3.2.3)
i wish you could grab the vertices display in the viewer to modify a mesh. maybe i'm hoping for to much.
i attached a screen shot and example mesh filter comp, for you to run.
are you saying you made a mesh vertices display macro or library patch and the mesh input port is missing or is of virtual type. if this is the case adding a splitter and setting it to be of type mesh could fix the problem. sometimes i find the library patches to act a bit wonky every now and then.
Re-read my comment. What I said was that the mesh vertices display had it's port unpublished in one of the updates. I don't need a sample comp on how to use it, and insert splitters have nothing to do with anything. The input to meshes are mesh, not virtual as well... I think we have some communication impasse where I don't understand what you mean. :-)
I'm trying to clearly figure out if this was fixed by Apple at any point, so that when someone places this patch on the patch creator, that it has a mesh input by default. Since I went into the patch and republished the input when I found it broken on an update, I have no clue when/if this has been fixed yet.... I see your pic, so I'm guessing it's ok.
Man, an invisible editor would drive me crazy!
What does grabbing the vertices display in the viewer to modify mesh mean? If it means what I think you mean, try doing something like putting a jiggle patch in between a your mesh importer, attaching it to mouse or interaction x/y. If you want you can do a sample and hold type of thing to freeze the vertices when you aren't interacting, or make a loop so that deforming is additive for sculpting.
well that is an interesting question, I had to get into the innards of the accompanying Mesh Normals Display file to make it a functional item not so long ago.
The file stamp date on my currently installed Mesh Vertices Display.qtz is for May 19th 2009, both Created & Modified. This is matched with a lot of other .qtz files in the System/Graphics/Quartz Composer Patches folder.
The file stamp date on my Mesh Normals Display.qtz reflects however the date when I first posted about that patches' lack of functionality. [ Feb 19th 2010 ]. Pre 10.6.3 and at that time Mesh Vertices Display was working AOK for me.
10.6.1 - Sept 10th 2009
10.6.2 - Nov 9th 2009
10.6.3 - Mar 29th 2010
10.6.4 - Jun 15th 2010
& on the basis of this admittedly slim evidence I do make & rest my case, namely that the Mesh Vertices display has not been directly updated since May 19th 2009.
What really puzzles me is why you would need to update it, but perhaps that is just the happen chance result of the installation & update route that I've travelled with 10.6.x differing from yours, GT.
Hope that helps.
Ah, it was mesh normals display.
I wasn't personally needing to update it (mesh vertices display), I just knew that one of the mesh display (vertices or normals) had been incorrect, and I wanted to know if I based something around using it, if it would actually make any sense to anyone if most people still have a patch with no mesh input, or if I would have to explain about fixing it.
Does this finally make sense why I'm enquiring? ;-)
However, I think I just decided not use either.
It already made sense dude , :-)
To guarantee that a composition doesn't break on a pretty standard OS X 10.6.x install by your relying on a patch that got broke somewhere between 'takes'.
Well Mesh Normals is great for creating outlandishly or even exquisitely small scaled lines , especially with some hue rotation on the line colour.
Mesh Vertices is great when you only want the Vertices, although you could use set or get component to do a similar trick and if it where vertices, I would probably opt for a Mesh Renderer to render with, especially for effective colouring and texturing.
As far as I can ascertain, no such update has been affected at all.
I've discovered some other lapses of concentration or slight coding errors in a couple of OpenCL kernels elsewhere. By now I have moved on from treating OpenCL as if these kernels need to be 'purged' or 'bled' like a good old mediaeval physician.
One of them's a real doozy though, it just makes me laugh.
This is actually the composition that got me asking about this, and it was early on in my conceptualization.
I decided I would rather use iteration anyway. I had to iterate for the lines, because I wanted to keep it all stock, and then I decided that I would rather be able to texture the "points", so I just used Sprites (again, instead of GL Points, because I wanted to use all stock patches).
I only wanted to visualize the vertices anyway.
wow that is nice!! thankx very much for posting the comp!
btw, how do you hide the .qtz comp inside the executable file instead of it being in the 'Resources' folder (inside the app contents)?
sorry i was confused about the whole unpublished virtual port thing. i realize you don't need a sample comp, but made to see if i could replicate the issue. yeah that was totally confusing, i'm like why would george be making macro of the vert display. its tiny as it is ? i get it now you had to edit apples macro to republish the mesh port as it disappeared on an update.
actually a see thru editor is awesome if your only using one monitor that way i can put the viewer under the editor and have more edit space. sucks if you have 2 editors open at the same time though.
sort of on the grabbing verts in viewer george. kind of like bulging the mesh based on your xy and storing the transformation. i was more or less talking about grabbing the point in the viewer and moving it with your mouse, but that would require some transformation handles or something given the nature of 3d space. you kind of how you would move some vertex points around in maya or cheetah 3d or something.
wow that bounces really nice george. do you think its possible with a quad like this to grab a single vert instead of the whole thing ?
Great comp. Smooth Action and a sweet Interaction concept.
BTW - the one you've posted onto the Box provokes an error
probably needs a fresh upload.
So you mean grabbing to sculpt with mouse and storing transformation after mouse up, like this? I'm using OpenCL filters and mouse movement to do a sculpt on a grid and sphere, but this could be applied to whatever.
I'll post this soon...
edit- http://kineme.net/composition/gtoledo3/OpenCLSculpt
Hmm, I guess it was probably in your download (maybe it didn't finish for some reason?). I just downloaded the qtz and the app, and they were both ok.
Yeppers, check above/what I just posted to the repository.
sort of mate, i made a patch that does this a while back. i was wondering if something like this would be possible in a future update of QC. (see pic) but yes i like bulge deformation modeling, i prefer to model that way organically with push and pull style. actually just got into voxel modeling, you can't rip polygon apart if you displace the verts to much with voxels.
i was just thinking some kind of universal transformation tool that could be used in the viewer like the pic. not really for verts as i like to push and pull when working in hi res but just to move anything around in qc kind of like the QC3DGUI patch but for objects i guess. i suppose its possible with some 3d hit testing and some gui style menu or something. don't know if that would just make qc like other apps, as it seems people prefer to move things around with numbers, which takes a bit getting used to for me.
Yeah, I think it was a lost packet, can happen, probably due in part to the lightning in the area, or the appallingly bad engineering practice of leaving the very last point of WAN connection down to an unmanaged Multiplex [resulting in gross sweating of the impedance values] - grrr.
{ bad engineering practice - driven by bottom line economics that inevitable ends up costing more in subsequent resets by visiting engineers }.
Anyhow just wanted to say that your Mesh Vertices Interaction construct is really great, the only thing that disappoints is not your fault, it's the system wide slow level of performance of 3D performance of Meshes of even relatively simple complexity in such a construct.
I replaced your textured grid with a simple 3d cone, and let that be either filtered or unfiltered and whilst it worked, it did not run at all as smoothly as the construct based upon your inclusion of a redraft of the Mesh [Dandelion picture] example.
You've quite rightly kept your grid to an easily manageable and renderable size. [Vertices numbering 100].
I love the inherent congruity of OpenCL. Quite literally for every doubling of the resulting Vertices count and other points computationally derived, there is a direct 50 % reduction in the fps achieved by the previous , smaller mesh. The example pictured performs fairly well, though it is nearly 300 % larger in point size than the grid mesh you've used.