I wonder if there is something I could do in the C++ exporter code to disable the optimizations or otherwise trigger a full update; it would be nice to not have to modify ice trees in order to get them to export correctly.
From: Eric Cosky [mailto:e...@cosky.com] Sent: Thursday, May 09, 2013 12:18 PM To: 'softimage@listproc.autodesk.com' Subject: RE: Looking for exporting tips with ICE topology - SI2014 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: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Fabricio Chamon Sent: Thursday, May 09, 2013 12:12 PM To: softimage@listproc.autodesk.com 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 <e...@cosky.com> 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.