Convert vertex map to polygon selection

[Srek]

I think baking out the shader as a series of image files is your best option.
Cheers
Björn

[typografschaft]

Thanks Srek, what a pity :-)
Is this because the live conversion would
result in a performance hit or would be
very complicated?

[Srek]

If you convert a weightmap to a selection you loose all possible shades since a selection tag only knows selected or not. The main problem however is that the order of execution simply does not allow for this.

[douwe]

I have ended up trying to use the Vertex Map Shader with a Birth Type set to Texture a few times myself to no avail.

So wanting to convert the map to a poly selection is an obvious choice, ye.
Loosing all shades wouldn't be the problem, since all you need for selecting Polygons is Booles anyway and it's simple to turn the Weightmap Values into Booles.
But then the question is indeed, what do you feed that into ?

you need to render a vertex map in a texture as well to be able to see it.
thanks for clearing up that it just can't be done, björn.

d

[Darter]

Points with weights > 0 can be stored as a point selection, which can in turn be converted to a poly selection and stored in a tag.

This example (http://bit.ly/ojtfLI) uses a morphed vertex map to drive texture assignment and PMatterWaves particle emission.

As pointed out by Srek, this doesn't allow for different shades to be taken into account so I'm not sure how useful this approach would be. An interesting exercise anyway.

[typografschaft]

How awesome is that!
You don't know how big the favor is you've done here, Darter.
Thank you very much!

Here's a setup I did with your coffee solution, the vertex map is driven
by a plain effector with a spline source in the falloff tab. The polygon selection
drives the clones and the particles. The vertex map also restricts a jiggle deformer,
the result invites to more exploration :-)
http://dl.dropbox.com/u/28253825/VertexMapsToPolySelection_yader.c4d

[Darter]

No worries typografschaft, I'm glad to see the expression being used to such good effect. It makes sense now that I can see what you were doing. That's an ingenious setup, I've learned a lot getting my head around it. I think your approach to driving Vertex Map values could have many uses.

I've updated the expression with User Data links for the vertex map and poly tags to make it easier to reuse.

[douwe]

very clever, david.
there's great stuff to be done with this concept.

about the coffee :
It's interesting how you loop through the points of each polygon to decide if it needs to get selected or not.

Now, I was wondering; all polys need to be quads for this setup to work.
I imagine, if I wanted to use this with a mesh that has tris and ngons, all this would take is another "for loop" to get the pointcount for each poly and compare that variable with your "found" variable, right ?

I got stuck at this part.
if(bs->IsSelected(poly->d)) found++;
Do I just put extra lines in there in case there are more points ( poly->e and f and g ,...) ?
Doesn't seem to behave though, and of course that's completely due to me being a coffee dummie.

could you give me a quick hint in the right direction ?
Would make this so much more flexible if it works with every single polygon you throw at it.

cheers,
d

[TimC]

Interesting stuff guys, thanks for the tips!

cheers
Tim

[Darter]

It's been an interesting learning exercise for sure, Tim.

Do I just put extra lines in there in case there are more points ( poly->e and f and g ,...) ?
Thanks for your interest douwe. It's working fine with Ngons and tris in all the tests I've done here.

As poly->c and poly->d are the same for triangles, this index is just counted twice and the test works. I figured there wouldn't be much difference in overhead between doing this and testing for tris first. The test works for Ngons as they're comprised of quads and tris at a lower level.

[douwe]

- As poly->c and poly->d are the same for triangles, this index is just counted twice.
- Ngons are comprised of quads and tris at a lower level.

thanks for this extra essential bit of insight, david.
All tests with ngons and tris appeared to be working fine here as well, also with more complex shapes.
It just didn't seem to be logical from what's happening in the code. "if(found == 4)"

I learnt a lot today.
thanks david, thanks derya.

d

[Darter]

All tests with ngons and tris appeared to be working fine here as well, also with more complex shapes.
Thanks for taking the time to test and confirm this, it's good to know that it's working reliably in other situations.

[typografschaft]

Following your code and succesfully copy&pasting I added a Treshold UserData
to the coffee tag, so one can determine at which weight value polygons are
actually selected.
I hope it's ok with you Darter?
http://dl.dropbox.com/u/28253825/VMapsToPolySelect.c4d

It's amazing what one can do with a couple of lines of code,
I'm impressed to say at least ;-)

[douwe]

yihaa, derya !!

this concept really is impressive.
been playing with PSurfacePosition,
and with your Moselector setup to turn this "vertex map/polygon selection" into a Moselection.

this treshold makes it even cooler.

[Darter]

Following your code and succesfully copy&pasting I added a Treshold UserData
to the coffee tag, so one can determine at which weight value polygons are
actually selected.
I hope it's ok with you Darter?
http://dl.dropbox.com/u/28253825/VMapsToPolySelect.c4d
No problem, that's a good enhancement. I'm having fun animating the threshold already.

One small thing, could you please correct the spelling of 'Treshold' to 'Threshold' in the User Data and code?

[typografschaft]

yihaa, derya !!

this concept really is impressive.
been playing with PSurfacePosition,
and with your Moselector setup to turn this "vertex map/polygon selection" into a Moselection.

this treshold makes it even cooler.

:-) Sounds nice, so one can affect specific clones based on the Vertex/polySelection, I think the concept of translating polygon/point selections, mograph selections and vertex maps on the fly can lead to crazy stuff, maybe one of the plugin guru's around here needs a challenge? ;-)

@Darter: typos has been corrected, the link in my post above has the new file.

[cgireal]

Thanks to this technique I was able to get nice collision dust from these tank tracks via the vertex-map output from the collision deformer.

Before I read this thread I was faced with the need for a tp-collision node set for EACH link of the tank tracks.

The problem is that when the collision deformer is cached it no longer updates/outputs the vertex map?? any ideas? so close and yet so far.. :(

http://s15.postimage.org/vj2qsq2t7/interactive_dust.jpg (http://postimage.org/image/lyj45udh3/full/)

[douwe]

maybe i misunderstand you,
but a quick reproduction seems to be working :
http://www.mediafire.com/i/?7sh3q5hb0ekjab3
jpg : http://www.mediafire.com/?7sh3q5hb0ekjab3

c4d : http://www.mediafire.com/?hg7poknwc32ug95
(calculate the cache + press play)

good luck,
d

sorry for the mediafire links, due to attachment limit.

[cgireal]

your file has exactly same issue, the vertex map becomes static after caching, at least on my pc it does.

your file actually demonstrates the problem really well.

[douwe]

confirmed.

got confused by your screenshot.
that xpresso window had me thinking your final goal was to get your Particles generated correctly.

the vertex map output doesn't update like you say indeed.
this should be fixed. anybody a workaround ?

d

[typografschaft]

This is an unfortunate limitation of the collision deformers cache – try to avoid it, if you want an up to date vertex map.
Or you use the Tension Tag for writing into a VertexMap instead of the collision deformer. But there is no caching there also…

[typografschaft]

What you can also do is to use a connect object and a correction deformer with a collision node.
Example attached.

[cgireal]

Thanks Yader, I really like this approach, and it works with r12 which is a great plus, (Maxon we await R14 and hope you'll undo all the crazy interface changes - WTF seriously sack someone!) anyway where was I... rant over...

The problem now becomes that the connect object reads the entire heirarchy for the trank tracks inc the high-poly beauty geometry which is a child of each link. I cant see anyway to stop that..

Thanks again, I'll keep trying and report back. My initial hunch is that I should be using another layer for the beauty geometry.. kind of avoided layers upto now....

EDIT; nope, layers didnt help, but I got a nice result from the tension tag with cached collisions, Big thanks :)

[typografschaft]

Maybe do Instances of the Proxy Geometry and group them and then reference that group with the Connect Object?

[cgireal]

Oh we've cross posted, did you read my edit?

Yes, instances would work for an r12 setup, I'll try and remember that. Cheers.

[typografschaft]

That's also a fine workaround, using cached collisions with the tension tag :-)

[cgireal]

heres my example;

http://www.mediafire.com/?yjej0c8djsic3b0

note, the threshold setting was essential in order to leave restore shape turned down on the coll deformer.

[echun]

yihaa, derya !!

this concept really is impressive.
been playing with PSurfacePosition,
and with your Moselector setup to turn this "vertex map/polygon selection" into a Moselection.

this treshold makes it even cooler.
??vertex map/polygon selection?

[Keith Young]

Hey guys,

This thread triggered my curiosity, so I ported Dater's original COFFEE script to a C++ plugin. I also added the Weight Threshold as well as a Poly Vert Threshold (lets you set how many (0-4) of the vertices of the polygon have to meet the Weight Threshold).

I only built it for R13, PC (both 32bit and 64bit) - see the attached file and included ReadMe.txt [EDIT: I removed the attachment... see me later post in this thread (http://forums.cgsociety.org/showpost.php?p=7352408&postcount=35) (on the next page)]

[NOTE: being a compiled C++ plugin may make it a little faster, but it's also not as convenient - the COFFEE script method makes it easier to make changes and/or more portable between versions and platforms... in other words, I don't intend to continue updating this plugin - if it's useful to you as-is, then great - if not, then you might want to stick with the COFFEE version :) ]

Cheers,

Keith

[cgireal]

Thank you, It works well :)

[typografschaft]

Thanks very much Keith, a Mac compile would be highly appreciated :-)

[Darter]

I did not include a copyright notice in the original expression. However I would have appreciated being asked as a matter of courtesy before my work, albeit modified, was converted to a copyrighted plugin.

My nick is Darter not 'Dater'.

[Scott Ayers]

It would also be wonderful to have the source files(.cpp & .h) included in the zip if possible too Keith.

Coffee and Python code are being shared a lot nowadays. Which is great because they are a great source to learn from.
But it's still very hard to find C++ source code included with freebies.
Don't forget about us C++ learners too guys.:)

Thanks,
-ScottA

[Keith Young]

I did not include a copyright notice in the original expression. However I would have appreciated being asked as a matter of courtesy before my work, albeit modified, was converted to a copyrighted plugin.

My nick is Darter not 'Dater'.

Sorry for the name typo - it's been corrected. I also apologize for any faux-pas related to not speaking to you before creating a C++ plugin based on your ideas/sample code.

I have just posted a R12 (or later) version on my site (http://skinprops.com), which includes the Visual Studio 2005 C++ source code and project file - distributed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License (http://creativecommons.org/licenses/by-nc-sa/3.0/).

Cheers.

[Scott Ayers]

Thank you Keith.

-ScottA

[Keith Young]

Thank you Keith.

-ScottA

No problem. BTW, I just uploaded a v1.1 update... the new version has an option to reverse the mapping (map the Polygon Selection tag to the Vertex Map tag).

The weighting is determined by the number of 'selected' polygons that use each point, vs the number of total polygons that use each point. In other words, if 4 polygons all use a common point, but only one poly is selected, then the weight for that point will be 25%. Two polys would give 50%, etc.

[Darter]

Sorry for the name typo - it's been corrected. I also apologize for any faux-pas related to not speaking to you before creating a C++ plugin based on your ideas/sample code.

I have just posted a R12 (or later) version on my site (http://skinprops.com), which includes the Visual Studio 2005 C++ source code and project file - distributed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License (http://creativecommons.org/licenses/by-nc-sa/3.0/).

Cheers.
Thanks for making these changes. Credit also goes to typografschaft for the initial concept.

It's good to see the plugin being updated, hopefully many people will find it useful.

I'm in the process of doing an OS X compile but it's taking longer than expected. I recently upgraded to Lion and XCode 3.2.6 refuses to save renamed project files. I've just installed 4.3 and will hopefully have more success.

[Keith Young]

...I'm in the process of doing an OS X compile but it's taking longer than expected. I recently upgraded to Lion and XCode 3.2.6 refuses to save renamed project files. I've just installed 4.3 and will hopefully have more success.

Ahh - I haven't upgraded to Lion, so let me know if you can't get it working and I'll see about getting a Mac compile done (the way I currently have to do Mac work is just a bit of a hassle, so I tend to procrastinate doing anything on the Mac).

A note (to everyone) on the new v1.1 update...

Since it can now either map Vertex Map -> Polygon Selection or map Polygon Selection -> Vertex Map, you might want to set that option to your intended goal as soon as you add the tag to your scene (or at least before you fill in the links to the tags, or put the tag on your mesh), so that it doesn't inadvertently mess up your map/selection. In other words, as soon as the tag is on a mesh object and has valid links, it starts 'working' (assuming it's 'enabled').

On a similar note... one of the included example files ("VertexMapsToPolySelection_young.c4d") which is a modification of the file Yader posted uses Expresso (I think) to modify the Vertex Map tag... if you also have this tag set to modify the Vertex Map tag, you'd get unexpected results (at best).

I could have just made it 2 separate tags, but I would have had to produce a second set of resource files, etc. (another thing that's easier to do with COFFEE, since you don't need the resource files at all).

[Keith Young]

To help give some visual feedback, as well as a programming exercise/example, I added some code to swap out the tag's icon, depending on which mapping mode is active. I also tidied up the code and comments somewhat.

The v1.2 update is now available on my site - I'm pretty much done with this now, unless people need something else from it.

Cheers.

[Darter]

I've sorted out my XCode 4.3 teething issues and have done a compile for OS X. The plugin seems to be working okay.

Due to changes from R13.058 onwards, it was necessary to add maxElements arguments to the GetRange() calls for the plugin to compile. Something to be aware of for future compiles.

Please note that crashing has been reported (http://www.plugincafe.com/forum/forum_posts.asp?TID=6854&KW=GetRange&PID=28604#28604) in relation to installing a plugin compiled for R13.058 in an earlier version of R13.

I still have Snow Leopard on my MacBook so if there's enough interest I can do an R12-compatible compile next week when time allows.

[Keith Young]

I've sorted out my XCode 4.3 teething issues and have done a compile for OS X. The plugin seems to be working okay.

Due to changes from R13.058 onwards, it was necessary to add maxElements arguments to the GetRange() calls for the plugin to compile. Something to be aware of for future compiles.

Please note that crashing has been reported (http://www.plugincafe.com/forum/forum_posts.asp?TID=6854&KW=GetRange&PID=28604#28604) in relation to installing a plugin compiled for R13.058 in an earlier version of R13.

I still have Snow Leopard on my MacBook so if there's enough interest I can do an R12-compatible compile next week when time allows.

Great... and yeah, I went back to R12 to avoid both of the issues you mentioned (the GetRange() issue as well as R13.012 vs R13.058 issues - which are likely one and the same).

For my other plugins, I'm only doing R13.012 builds (if I need an R13 build at all - R12 builds still work in R13 so far...). Adding that maxElements argument was one of the first REALLY BAD IDEAs that has ended up in MAXON's (same-major-release) SDKs -usually they wait for a new major version for changes like that - and occasionally even think to add it as the LAST arg, with a default value.

[Darter]

Default argument: no-brainer. Sticking it in the middle of the parameter list is bonkers.

I really need to get XCode 3.2.6 working under Lion as I have to upgrade my MacBook next month when Rhino stops working under Snow Leopard.

Rather than leave the potential crashing issue in limbo, I've found the time (FIVE minutes) to do an R12 compile. I've sent the link via PM.

[Keith Young]

...Rather than leave the potential crashing issue in limbo, I've found the time (FIVE minutes) to do an R12 compile. I've sent the link via PM.

Excellent - thanks! - As we discussed in PM, I've included your Mac build (and xcode project file) in the archive.

Thanks again.

[cgireal]

Good work guys, thanks...

Just wondering if anyone had a good idea for applying the inverted functionalitity, converting polyselection > vertexmap? are their obvious uses? my brains on strike this morning.. thanks.

[Keith Young]

Good work guys, thanks...

Just wondering if anyone had a good idea for applying the inverted functionalitity, converting polyselection > vertexmap? are their obvious uses? my brains on strike this morning.. thanks.

Good question :) ... of course I never knew anyone would have a use for the original idea, so I just assumed someone would / could use the opposite functionality (that, and I just enjoy working out the details on such things).

[typografschaft]

Maybe this will give you some ideas:
https://vimeo.com/35222996
I approached Paul Everett with the idea and he was kind enough to build a plugin out of it and group it together with his additional effectors.

[Keith Young]

Wow - neat stuff! I still haven't even tried half the stuff available in the basic app :).

[cgireal]

Lots of ideas in that vid - thanks, but its really hard to follow at a conceptual level.
Afterwards I checked Pauls site and discovered his Fit effector , which prevents mograph clones overlapping... HOORAY, needed that so many times, always expected Maxon to fix this overlapping issue but its still there.