Re: Looking for exporting tips with ICE topology - SI2014
In ICE, you can pull an attribute from a node context and write it back to a UV property, but I wouldn't exactly say it's a stable or recommended workflow. Honestly, updating your exporter would be simpler, but in that case you almost certainly will encounter the previously mentioned aggresive ICE optimizations... On Fri, May 10, 2013 at 12:08 AM, Eric Cosky wrote: > Thanks! That’s very helpful. I suppose it’s probably possible to add some > nodes to push the attributes into the cluster so the exporter will see the > final results..? I’m not sure what the limits are there with respect to ICE > working with UVs like this. While I’d hoped to not have to specialize the > ice tree, if this is a valid option it might be easier/simpler to do this > than modify the exporter to look for the ice attributes. > > ** ** > > *From:* softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] *On Behalf Of *Steven Caron > *Sent:* Thursday, May 09, 2013 3:55 PM > > *To:* softimage@listproc.autodesk.com > *Subject:* Re: Looking for exporting tips with ICE topology - SI2014 > > ** ** > > 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 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:* softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] *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 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:* 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 > > 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
Re: Looking for exporting tips with ICE topology - SI2014
change the c++ to get ice attribute directly or change the ice tree to set the uv cluster property... its up to you :) On Thu, May 9, 2013 at 4:08 PM, Eric Cosky wrote: > Thanks! That’s very helpful. I suppose it’s probably possible to add some > nodes to push the attributes into the cluster so the exporter will see the > final results..? I’m not sure what the limits are there with respect to ICE > working with UVs like this. While I’d hoped to not have to specialize the > ice tree, if this is a valid option it might be easier/simpler to do this > than modify the exporter to look for the ice attributes. > > ** >
Re: Looking for exporting tips with ICE topology - SI2014
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 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 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:* softimage-boun...@listproc.autodesk.com [mailto: >> softimage-boun...@listproc.autodesk.com] *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 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:* 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 >> >> 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 >>
RE: Looking for exporting tips with ICE topology - SI2014
Thanks! That's very helpful. I suppose it's probably possible to add some nodes to push the attributes into the cluster so the exporter will see the final results..? I'm not sure what the limits are there with respect to ICE working with UVs like this. While I'd hoped to not have to specialize the ice tree, if this is a valid option it might be easier/simpler to do this than modify the exporter to look for the ice attributes. From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Steven Caron Sent: Thursday, May 09, 2013 3:55 PM To: softimage@listproc.autodesk.com Subject: Re: Looking for exporting tips with ICE topology - SI2014 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_1Geo metry_html,hash=a6175a2d732e2f4dd00ebb25435bb163d On Thu, May 9, 2013 at 3:01 PM, Eric Cosky 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-4 0.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: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] 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 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: 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 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
Re: Looking for exporting tips with ICE topology - SI2014
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 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:* softimage-boun...@listproc.autodesk.com [mailto: > softimage-boun...@listproc.autodesk.com] *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 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:* 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 > > 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 e
RE: Looking for exporting tips with ICE topology - SI2014
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-4 0.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: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] 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 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: 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 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 d
Re: Looking for exporting tips with ICE topology - SI2014
If you don't want to modify the icetrees, you can still do Get Property->Attribute Display and set it to show your fancy attribute. This is the exact same as "Show Values", but at the object level. On Thu, May 9, 2013 at 3:32 PM, Eric Cosky wrote: > 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 > > 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. > > > > ** ** >
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 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:* 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 > > 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. > > > > > ** ** >
RE: Looking for exporting tips with ICE topology - SI2014
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 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.
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 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.
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 > 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. > > > >
Looking for exporting tips with ICE topology - SI2014
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. <>
