Yeah, in your example scene, you've created a texture projection on your copy geometry and you're attempting to write the UVs that. Forget about using standard texture projections with ICE topo - just store UV data in a custom vector ICE attribute. Of course, you'll have to modify your exporter to pull the data from ICE not from a cluster property.
On Thu, May 9, 2013 at 11:54 PM, Steven Caron <[email protected]> wrote: > 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. >> >> **** >> >> **** >> >> ** ** >> > >
