For what I know, particles cannot get any UV. So, every particle (or geometry attached to particle) will get only the color. It's a kind of limitation.
C4D does it, for example. It can spread and image on N objects generated, like cubes, for example, and each one gets it's piece of UvMap. It's cool. 2013/10/2 Rob Chapman <tekano....@gmail.com> > no worries Olivier, just wanted to see if it was possible. kind of fumbled > through wishing for the best than knowing exactly what was happening. mine > is not exactly on but maybe you can make it work - here is the scene (2013) > anyways. hope it helps! > > > https://docs.google.com/file/d/0B0WD7fSUkxAMenR5d014ZHd3RHc/edit?usp=sharing > > > > > On 2 October 2013 07:51, olivier jeannel <olivier.jean...@noos.fr> wrote: > >> Hey Rob, >> Thank's buddy ! >> That's what I had, except for the Transform node that finally I didn't >> use (tryed to get an rotation or an invert rotation, but the result was >> "less" good. >> Can you tell me how you're using it ? >> Also, >> >> I directly plugged the Vector Attribute, no Vector-Vector, can you tell >> me your settings for this Vector-Vector ? >> >> And also, >> >> I used direct shape "circle" so that I couldn't visualy see the Uvs, your >> solution is better. >> >> I'll try to post something. In my result it was almost good, except the >> texture was average aligned, with sometimes un exact offset. But the >> result was ok enough... >> >> My main problem beeing I have to jump from pictures to pictures almost on >> a day basis, leaving little time for Ice developpement :( >> >> Thanks again for your precious help ! >> >> Olivier >> >> >> Le 02/10/2013 00:56, Rob Chapman a écrit : >> >> eet is not 12 oclock yet oiu? >> >> >> http://24.media.tumblr.com/51cf2f589b534889e475b4ec17149432/tumblr_mu0i6qchOr1r3czqwo1_1280.jpg >> >> :) I think Graham was right but you also have to use instances with a >> texture UV but also shares the same material as the pointcloud and has >> access to the attribute.. >> >> any way I had a fiddle and kind of got there by scaling and offsetting >> the UV's on the instance object >> >> >> On 1 October 2013 14:21, olivier jeannel <olivier.jean...@noos.fr> wrote: >> >>> I've tried, but no luck (yes using the Edit_Uvs node) I thought I could >>> invert the rotation (like an invert Matrix) before, but, nope. Got Less >>> good result. I'm sure it's possible, I'm 2 fingers from it... ^^ >>> >>> I hope some one will show the good graph someday, there's a good way to >>> do it that's sure. >>> Could save a graphist, but nowaday all the attention is focussed on >>> pandas... >>> >>> Le 01/10/2013 15:10, pete...@skynet.be a écrit : >>> > perhaps (just perhaps) you can get there with the edit_UVs node - it >>> does >>> > allow to rotate UVs. >>> > so maybe if you rotate the UVs first (based on particle rotation), and >>> then >>> > give them the scaling and translation offset ? >>> > rotating afterwards sounds more tricky with the offset and all >>> > >>> > -----Original Message----- >>> > From: olivier jeannel >>> > Sent: Tuesday, October 01, 2013 1:43 PM >>> > To: softimage@listproc.autodesk.com >>> > Subject: Re: Particle "taking uvs" from it's emitter >>> > >>> > Just copying his rendertree and using the "my-Uvs" as Offset gives >>> > promising results. >>> > Now I just need something to correct my orientation : it's super in >>> > facing X axis particles, but mines need to have some oriention... >>> > >>> > >>> > Le 01/10/2013 13:11, pete...@skynet.be a écrit : >>> >> sprite node in the rendertree is just a way of doing tranparency (its >>> >> resetting the raycount on each incursion I think) - so you can get >>> through >>> >> a >>> >> lot of transparent surfaces without increasing the raydepth. It has >>> >> nothing >>> >> helpful to offer to help with uv coordinates on particles. >>> >> >>> >> particles in softimage are points - and you can give them a single UV >>> >> value >>> >> easily enough - as discussed here that will just enable you to get the >>> >> proper color for the texture map. >>> >> certain shapes have uv coordinates built in - such as the sphere or >>> >> rectangle - which by default will map a single image on the entire >>> >> surface. >>> >> the obvious solution is to combine the single color from the >>> underlying >>> >> texture with a transparency map on the particle to give them some >>> shape >>> >> and >>> >> variation - it can give you the (flawed) appearance of tearing up a >>> >> surface >>> >> into pieces - (hint: besides the uv you can also use the normal at the >>> >> surface which will give you identical shading - very helpful!) - but >>> its >>> >> not >>> >> gonna be a proper crop from the texture on the emitting surface. >>> >> >>> >> by calculating proper UV remap values you can crop a part of an image >>> - so >>> >> technically your solution is there. (if you're fine with flat >>> rectangular >>> >> particles that is) and the link you gave seems to have solved that. >>> With >>> >> an >>> >> ordered grid with a rectangular mapping it shouldn’t be too hard to >>> do. >>> >> 5x5 >>> >> grid - so each particle will have coords from 0-0.2 with offsets in >>> >> multiples of 0.2 in U and V - you get the idea. >>> >> >>> >> With an arbitrary polymesh surface, having an arbitrary UV set, likely >>> >> with >>> >> seams and arbitrarily sized particles, calculating those proper remap >>> >> values >>> >> is much more complex, and way above my head for sure. >>> >> In such a situation I'd rather got the route of fracturing the >>> object, and >>> >> instancing the individual pieces to particles - but that is quite a >>> >> different proposition and you will hit performance problems with 100k >>> >> particles for sure. And there is Guillaume's addon to transform >>> polygons >>> >> by >>> >> particles - which is very nice for performance - if the shape of >>> >> individual >>> >> polygons is ok for you. >>> >> >>> >> -----Original Message----- >>> >> From: olivier jeannel >>> >> Sent: Tuesday, October 01, 2013 12:18 PM >>> >> To: softimage@listproc.autodesk.com >>> >> Subject: Re: Particle "taking uvs" from it's emitter >>> >> >>> >> Damn, that's annoying... >>> >> What about the Sprite node ? >>> >> SecondReality did something >>> >> https://vimeo.com/34463159 >>> >> But on a grid (my object is 3D with a lot of particles and overlaps) >>> >> >>> >> Le 01/10/2013 12:05, pete...@skynet.be a écrit : >>> >>> you're not missing something, this is totally normal. >>> >>> at any given position (location) you have a single UV coordinate >>> (one u >>> >>> and >>> >>> one v value) - so that will result in a single color for the whole >>> of the >>> >>> particle. >>> >>> >>> >>> in order to get the corresponding crop from the texture, you would >>> need 4 >>> >>> uv >>> >>> coordinates for the four corners of a grid assuming your particle is >>> a >>> >>> rectangle - but a particle is a single point so that’s just not >>> going to >>> >>> work. (yes - you could save 4 attributes but you can't interpolate >>> >>> between >>> >>> them in the rendertree) >>> >>> I guess *in theory* it could be done, by calculating proper values to >>> >>> drive >>> >>> the UV remap in a texture node, for each particle based on it's >>> position >>> >>> in >>> >>> the UV set and size - and saving those in a number of attributes - - >>> but >>> >>> this is far from trivial. And you couldn’t account for seams in the >>> map. >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: olivier jeannel >>> >>> Sent: Tuesday, October 01, 2013 11:18 AM >>> >>> To: softimage@listproc.autodesk.com >>> >>> Subject: Re: Particle "taking uvs" from it's emitter >>> >>> >>> >>> Sorry Grahame, but it's not working. I mean it just gives a a color >>> to >>> >>> the particle, but not the piece of texture Uvs corresponding to its >>> Emit >>> >>> Location. >>> >>> Here's a screengrab, I probably miss something : >>> >>> >>> >>> Le 30/09/2013 21:11, Grahame Fuller a écrit : >>> >>>> Plug Self.EmitLocation into the source port of a Get Data, then get >>> >>>> cls.Texture_Coordinates_AUTO.Texture_Projection.UVs. >>> >>>> >>> >>>> gray >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -------------------------- >>> >>> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with >>> subject >>> >>> "unsubscribe" and reply to the confirmation email. >>> >>> >>> >>> -------------------------- >>> >>> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with >>> subject >>> >>> "unsubscribe" and reply to the confirmation email. >>> >> -------------------------- >>> >> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with >>> subject >>> >> "unsubscribe" and reply to the confirmation email. >>> >> >>> >> -------------------------- >>> >> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with >>> subject >>> >> "unsubscribe" and reply to the confirmation email. >>> > -------------------------- >>> > To unsubscribe: mail softimage-requ...@listproc.autodesk.com with >>> subject >>> > "unsubscribe" and reply to the confirmation email. >>> > >>> > -------------------------- >>> > To unsubscribe: mail softimage-requ...@listproc.autodesk.com with >>> subject "unsubscribe" and reply to the confirmation email. >>> >>> -------------------------- >>> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with >>> subject "unsubscribe" and reply to the confirmation email. >>> >> >> >> >> -------------------------- >> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject >> "unsubscribe" and reply to the confirmation email. >> >> >> >> -------------------------- >> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with >> subject "unsubscribe" and reply to the confirmation email. >> > > > -------------------------- > To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject > "unsubscribe" and reply to the confirmation email. > -- ...superpositiviii...qualunque cosa accada!...
-------------------------- To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject "unsubscribe" and reply to the confirmation email.
