create copies from mesh uses an ice attribute called 'Texture_Projection' it doesn't set the uvs of a cluster property directly. you want to get the ice attribute and you will probably be good.
http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/index.html?url=si_cpp/classXSI_1_1Geometry.html,topicNumber=si_cpp_classXSI_1_1Geometry_html,hash=a6175a2d732e2f4dd00ebb25435bb163d On Thu, May 9, 2013 at 3:01 PM, Eric Cosky <[email protected]> wrote: > Makes sense. I’d have hoped the results of the “Create Copies from Polygon > Mesh” node wouldn’t be subject to that kind of logic though. For example, > here’s the tree I am using in my scene: > https://www.dropbox.com/s/dlay4s9y5a30clm/XSIFloatingView_2013-05-09_14-40-40.png > **** > > ** ** > > I’m not much of an ICE guy, but I don’t see how to hook in a log values > node without digging deep into the Create Copies node.**** > > ** ** > > The other thing is, it does have the correct UVs if I render it, just not > at the time of export (but not consistently.. which is stranger than never > having the right uvs). This leads me to believe I am not requesting the > data correctly, somehow. I’m just using a geometry accessor, the > ga.GetUVs() and then the uv ClusterProperty.GetValues(). Maybe this is > giving me the raw, unprocessed pre-ice UV data and I need to look somewhere > else for the final result. That wouldn’t explain why one model has the > right data and the other doesn’t, but maybe that could be a different kind > of issue.. who knows. **** > > ** ** > > Thanks for the suggestions/comments**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Alan Fregtman > *Sent:* Thursday, May 09, 2013 12:52 PM > *To:* XSI Mailing List > > *Subject:* Re: Looking for exporting tips with ICE topology - SI2014**** > > ** ** > > The "aggressive optimization" problem is that ICE won't evaluate chunks of > a tree if it doesn't feel you are genuinely using it.**** > > ** ** > > So if I make some crazy math and store an attribute, if I don't use the > attribute anywhere, it actual doesn't really exist and its tree won't > evaluate fully. "Show Values" forces it to eval, as it needs this to > display the values.**** > > ** ** > > ** ** > > On Thu, May 9, 2013 at 3:17 PM, Eric Cosky <[email protected]> wrote:**** > > I’m not familiar with the ice optimization problem but it sounds like a > reasonable explanation for what I’m seeing. Thanks for the suggestion.**** > > **** > > **** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Fabricio Chamon > *Sent:* Thursday, May 09, 2013 12:12 PM > *To:* [email protected] > *Subject:* Re: Looking for exporting tips with ICE topology - SI2014**** > > **** > > Probably hitting the ice optimization problem? Make sure your UVs are > correctly set by putting a log values just before your set data node.**** > > **** > > 2013/5/9 Eric Cosky <[email protected]>**** > > Hi, > > > > I've recently started using ICE modeling to help with some low poly models > with tiny textures. The general idea is to make very small components, set > up the UVs as needed, then make a larger model that is composed of many > copies of the component. I like this approach because it lets me adjust > pieces after they have been put into place, including the texture > projections which will be propagated at any time in the future when the > original model changes unlike how clone seems to work. With the low > poly/low > res textures, it's not always obvious what the best look is going to be > until it's all together so being able to edit everything including texture > projections is pretty helpful to the workflow. Here's an example: > https://dl.dropboxusercontent.com/u/36497436/misc/ice-model.jpg - the ring > is made of the two parts shown in front, and it's using just a fraction of > a > 128x128 texture. If anyone is interested in looking at the scene, it's > here: > https://dl.dropboxusercontent.com/u/36497436/ThunderMoon/Portal.zip > > > > > > The modeling technique generally works as expected, but I am finding that > the UVs are not reliably available in the final ice model during export. > For > instance, the inner ring was exporting the UVs correctly, but not the outer > - all UVs on the outer were the same (I think [0,1], possibly the original > projection values which ICE was supposed to override). The exporter is > written in C++ and works correctly for exporting UVs on normal models, but > it seems like I have to freeze the modeling to get the UVs to be available. > Is this a typical thing to need to do with ICE modeling? Hopefully freezing > isn't a requirement for proper export. The strange part about it is the > inconsistency between the two ring parts, how one of them exports the uvs > properly and the other doesn't despite being identically configured (as far > as I can tell). This isn't a huge problem, just a workflow thing I'm trying > to understand & optimize before diving into more assets. If freezing is > required, so be it, would be nice to know if I'm just doing something wrong > though. > > > > Also, I am occasionally finding SI2014 gets into a strange state where one > or more of the ICE models just doesn't appear. It is selectable, but has > zero triangles/verts. When this happens the only thing I found to make them > reappear was to move the object in the hierarchy, which of course seems > like > a bug but perhaps I am just missing something here. If nobody else is > seeing > this I wonder if it has something to do with the use of RTShaders. I was > thinking perhaps shuffling the current frame to/from the first frame of the > scene might help but it doesn't, the only thing that fixed it for me was > moving the objects in the hierarchy. > > > > Any tips or suggestions on typical problems & workarounds for dealing with > ice models in the context of exporting the assets would be appreciated, > thanks. > > **** > > **** > > ** ** >
