Breaking up an object for that purpose is the same as assigning a local material to each polygon. No need to touch the geometry.
There are a variety of ways to do this, it's just a matter of what features and control you prefer. The first problem is how to decide which image(s) are applied to which polygons. The second problem is how to control the images once they're on the polygons (orientation, cropping, animation, ...). The old school solution is apply a unique material to each polygon so the assigned texture image shader can isolate it. The pro is this is easy to setup (or script), you can use static images or image sequences independently between polygons, and you have lots of control if you need to use passes and overrides to modify color or other effects. The con is in the event you need textures to expand (or contract) beyond polygon borders, then you're kind of caught between a rock and hard place, and navigation in the explorer might become a bit overwhelming. If you like development, you could write a shader to manage the images and polygons. Coding is close to trivial. The only tricky part is having control over which image gets placed on which polygon. The shader would prefer triangle ID, but users don’t tend to like that as there is no control over ordering of the triangles of an arbitrary mesh. A weight map could determine where images are placed. The pro of this solution is it would keep your scene neat and tidy and you could put logic into the shader to control all images en masse with ease (animate over time, for example). The con is you have to know something about writing mental ray shaders (not difficult, but takes time) and you would have to know the maximum number of images needed ahead of time as you have to code that into the shader's .spdl. Another shading driven solution is to use a concept similar to UV Remap where an image file (or programmatically driven color) defines which image is placed at a given texel. The color intensity (lightness) would act as a ratio within the image sequence and choose the nearest image. A 2nd image file could be used to drive other parameters such as animation, orientation, and so on. The pro of this solution is you are not bound to polygon borders and you have lots of control. The con is you might get some aliasing if your remap color is file based, setting this up could take considerable time, and you deprive yourself of granular control for passes and overrides if needed as your images would essentially belong to a single material. Although this could be set up in ICE, it would be better and more efficient to do it in the render tree. .ptex. Cannot remember if this is supported in Softimage or not, but that is essentially what is being requested here. If you push your images into such a format, then maybe this is an option(?). Matt Date: Wed, 24 Feb 2016 18:23:10 +0000 From: Adam Seeley <adammsee...@gmail.com> Subject: Re: 1 texture per polygon To: "softimage@listproc.autodesk.com" <softimage@listproc.autodesk.com> Hi, Haven't looked through the whole thread, but would it make it easier to splitting the polys into separate objects.. organising your uvs/images & then merging again? A. ------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
