in case you didn't notice
i know that tim is to humble to post it here, but these are to great and beautiful to go without some proper recognition. nissan altima fx design concept eye candy, https://vimeo.com/48823907 part1 https://vimeo.com/54739307 part2 giving me goosebumps. great work tim! sebastian
Re: in case you didn't notice
Their work is so sick! Great job! Eric Thivierge http://www.ethivierge.com On Mon, Dec 3, 2012 at 8:27 PM, Sebastian Kowalski l...@sekow.com wrote: i know that tim is to humble to post it here, but these are to great and beautiful to go without some proper recognition. nissan altima fx design concept eye candy, https://vimeo.com/48823907 part1 https://vimeo.com/54739307 part2 giving me goosebumps. great work tim! sebastian
Re: in case you didn't notice
Their work is so sick! Great job! Eric Thivierge http://www.ethivierge.com On Mon, Dec 3, 2012 at 8:27 PM, Sebastian Kowalski l...@sekow.com wrote: i know that tim is to humble to post it here, but these are to great and beautiful to go without some proper recognition. nissan altima fx design concept eye candy, https://vimeo.com/48823907 part1 https://vimeo.com/54739307 part2 giving me goosebumps. great work tim! sebastian
Re: filename length limit
What a shame that UNC trick doesn't work with XSI On Fri, Nov 30, 2012 at 6:18 PM, Luc-Eric Rousseau luceri...@gmail.comwrote: it's the Windows API that usually has a 260 char limit, unless you specially code your app to use long paths (there is a weird UNC trick) It's not a limit of NTFS or the network backend, but of most of the APIs. http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx On Fri, Nov 30, 2012 at 10:22 AM, Ales Dlabac adla...@gmail.com wrote: Actualy Windows is not restriction for us because our storage is on Linux machine. I've simplified example to windows c: drive. I don't realy understand why XSI limits this if windows can create longer names. Huh. I also noticed if you enable skip rendered frames XSI thinks image exists even if isn't. On Fri, Nov 30, 2012 at 2:07 PM, Adam Seeley adam_see...@yahoo.comwrote: Interesting, I thought it still was... I still get Windows throwing the error up when copying deep folder structures or Unzipping files sometimes. Have to have a closer read of your link... Adam -- *From:* Sajjad Amjad sajjad.am...@gmail.com *To:* softimage@listproc.autodesk.com *Sent:* Friday, 30 November 2012, 12:46 *Subject:* Re: filename length limit It's not really a Windows limitation anymore. My guess is that Softimage isn't converting paths to UNC (internally or accepting the forced UNC path format i.e. \\?\d:\32k path), details: http://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath On 30 November 2012 12:20, Alok Gandhi alok.gandhi2...@gmail.comwrote: It should work only thing is it will not show in the PPGs. But I am not sure. On Friday, November 30, 2012, Ales Dlabac wrote: Hey guys, I would like to know if somebody found solution how to use filename longer than 260 chars. Filename here is path + filename + frame + extension. You can test it yourself if you run this command in VBscript SetValue Passes.Default_Pass.Main.Filename, c:\aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyy If you delete one or more chars it starts to work. Unfortunately we sometimes run over this length due to folder structure and I can not think other solution than shortening folder names what is awkward for me. Thank you Ales --
Re: Python equivalent of C++'s GetRenderHairAccessor
Maybe by inspecting the hair.GetActivePrimitive2() you could find something, but I doubt it (and I can't test it since I don't have XSI at home). GetRenderHairAccessor return a CRenderHairAccessor object which I would be surprised if it would be COM compliant (for lack of a better word, just saying I don't know how it would be possible to return it to python via a custom command). But while I'm typing these lines, it seems like the object model has something called siRenderHairAccessorID ... might worth investigating. good luck On Mon, Dec 3, 2012 at 9:17 PM, Simon Anderson simonbenandersonl...@gmail.com wrote: Why you no use ice! XD haha.. jokes aside, what you trying to achieve, havent looked at soft hair in a long time. On Mon, Dec 3, 2012 at 6:01 PM, Jared jared.gl...@triggerfish.co.zawrote: RenderHairAccessor -- --- Simon Ben Anderson blog: http://vinyldevelopment.wordpress.com/ -- Xavier
Re: Python equivalent of C++'s GetRenderHairAccessor
For hair points you can do this, and then work out the subcomponent to there corresponding Position array (sure i did something like this for some script at TFish at some point, just taking a look at the way its layed out looks very familiar) hair = selObj.ActivePrimitive.GetGeometry2(1) lm( hair.Points.SubComponent ) lm( hair.Points.PositionArray ) Im not sure what else you are wanting to retrieve, but I think if you just do alot of looking at the SDK window and go through the parameters and properties and Nested objects you should be able to find alot of information that you can pull out. the help files on hair is none existent! GAAH!!! sdk mentions a hair primitive, but in the sdk theres no such thing. drop me a mail if you need any help Cheers Bed time, aka time to do some programming of my own before falling out of my chair into bed, strategical placed O YEAH On Mon, Dec 3, 2012 at 9:32 PM, Jared jared.gl...@triggerfish.co.za wrote: Hey, lol ask the ICE Monkeys here, they're the very reason I'm doing this :p I need to get things like the vertex positions etc from the hair to re-create curves and am trying my best not to have to learn c++ in the process (which I'm doing anyway but its taking a little while). Any ideas? And hope you're keeping well man, Jared On 2012/12/03 12:17 PM, Simon Anderson wrote: Why you no use ice! XD haha.. jokes aside, what you trying to achieve, havent looked at soft hair in a long time. On Mon, Dec 3, 2012 at 6:01 PM, Jared jared.gl...@triggerfish.co.zawrote: RenderHairAccessor -- --- Simon Ben Anderson blog: http://vinyldevelopment.wordpress.com/ -- Kind Regards, Jared Glass jared.gl...@triggerfish.co.za | Technical Lead http://triggerfish.co.za/en http://www.facebook.com/triggerfishanimation http://www.twitter.com/triggerfishza -- --- Simon Ben Anderson blog: http://vinyldevelopment.wordpress.com/ twitter-bird-white-on-blue.pnglFV-lsMcC_0.pnglogo.png
Re: in case you didn't notice
Haven't see there was an opus II ! Just brillant ! So much poetry in those researches... Le 03/12/2012 11:02, Nick Angus a écrit : A small taste of what you get when you put Eric Mootz, Christian Keller and Tim Borgmann in the same sandbox to play... Nick Angus | 3d Supervisor Alt Vfx www.altvfx.com http://www.altvfx.com On 03/12/2012, at 7:43 PM, Eric Thivierge ethivie...@gmail.com mailto:ethivie...@gmail.com wrote: Their work is so sick! Great job! Eric Thivierge http://www.ethivierge.com On Mon, Dec 3, 2012 at 8:27 PM, Sebastian Kowalski l...@sekow.com mailto:l...@sekow.com wrote: i know that tim is to humble to post it here, but these are to great and beautiful to go without some proper recognition. nissan altima fx design concept eye candy, https://vimeo.com/48823907 part1 https://vimeo.com/54739307 part2 giving me goosebumps. great work tim! sebastian
Re: in case you didn't notice
Breathtaking! On Mon, Dec 3, 2012 at 10:54 AM, Tim Borgmann i...@bt-3d.de wrote: Thanks Sebastian, and thank you all for the really great feedback :) Tim i know that tim is to humble to post it here, but these are to great and beautiful to go without some proper recognition. nissan altima fx design concept eye candy, https://vimeo.com/48823907 part1 https://vimeo.com/54739307 part2 giving me goosebumps. great work tim! sebastian -- Best Regards, * Stephen P. Davidson** **(954) 552-7956 *sdavid...@3danimationmagic.com http://www.3danimationmagic.com
Re: in case you didn't notice
Wonderful! On 12/3/2012 4:27 AM, Sebastian Kowalski wrote: i know that tim is to humble to post it here, but these are to great and beautiful to go without some proper recognition. nissan altima fx design concept eye candy, https://vimeo.com/48823907 part1 https://vimeo.com/54739307 part2 giving me goosebumps. great work tim! sebastian
RE: reorder custom parameters
The whole point of using the self-installing custom properties is you can build
a more robust and reliable toolset around them.
One issue encountered with using tools to work with custom properties is
figuring out what custom property you have so your tool knows what it should
do. If you query a custom property created using the Animate Parameter menu
using the SDK, it will always return 'customparamset' as it's type which means
you are relying on the name as the identifying key. If you use a self
installing custom property, it will report the plugin name as its 'Type' which
is fixed and does not change.
Example:
// CustomParamSet
var oCustomParamSet = ActiveSceneRoot.AddProperty( Custom_parameter_list,
false, joe );
LogMessage( Name: + oCustomParamSet.Name );
LogMessage( Type: + oCustomParamSet.Type );
LogMessage( Class: + Application.ClassName( oCustomParamSet ) );
// Self installing custom property
Var oCustomProperty = ActiveSceneRoot.AddProperty( TextProp,
false );
LogMessage( Name: + oCustomProperty.Name );
LogMessage( Type: + oCustomProperty.Type );
LogMessage( Class: + Application.ClassName( oCustomProperty
) );
The importance here is when you want to write queries and selection filters.
With a self installing custom property you can isolate specific custom
properties to make your tools more reliable and robust by filtering by the
custom property's Type. Useful after you've made a call to FindObjects() and
need to whittle the result list down a bit further for your purposes. In the
event you want to update the custom property's parameter list or make other
changes, the self installing plugin has version information which can be
leveraged to target which properties need to receive the updates when a scene
or model is loaded. You you no such information available with
customparamsets which means you are running blind.
Example:
var oCustomProperties = FindObjects( , CLSID_CUSTOMPROPERTIES );
// find only CustomProperties of type Text Prop in the results
var oFilteredCustomProperties = oCustomProperties.Filter( TextProp );
This is especially useful when using the Collection argument handler in self
installing commands as Softimage will replace empty arguments of this type with
the current selection in the scene. If your code is expecting a collection of
custom properties of a specific type, you can use the .Filter() method to
quickly validate the incoming data and minimize surprises downstream.
With customparamsets you must iterate through the collection and filter it
manually which can be expensive on large scenes and not terribly reliable:
Var oCustomProperties = FindObjects( , CLSID_CUSTOMPROPERTIES
);
for ( var i = 0; i oCustomProperties.Count; i++ ) {
var oCustomProperty = oCustomProperties(i);
If ( oCustomProperty.Type == CustomParamSet )
{
// it's a
customparamset...that's all we know so far.
// Must check the
customparamset's name and hope it hasn't been mangled or renamed by user.
If ( oCustomProperty.Name ==
name ) {
// must employ
additional logic in case multiple properties exist in the scene of various
versions
If (
oCustomProperty.Parameters.Count == some known number ) {
// we *might* have what we want.
}
}
}
}
Artists left to their own measures would not be expected to use self installing
custom properties, but for those looking to save time and energy, it's a smart
way to work and doesn't require much in the way of learning.
Matt
From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Alan Fregtman
Sent: Saturday, December 01, 2012 5:07 PM
To: XSI Mailing List
Subject: Re: reorder custom parameters
I'm still a big fan of this plugin to do logicless layouts:
http://www.softimageblog.com/archives/172
Yea, it needs a plugin, but with the one plugin you can have all the custom
paramset layouts you want! (No logic though.)
On Fri, Nov 30, 2012 at 5:23 PM, Matt Lind
ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote:
I'm not suggesting people use custom properties as one-off applications.
With the addition of workgroups to make installation a drag and drop operation
and the benefits self installing custom properties provide, there's really no
reason why they shouldn't be used and preferred over customparamsets.
Re: OT_ Here is some work I did for Blue Man Group using Softimage and ICE
Nice work! Is it wrong that I was watching the video with the sound off while listening to Neil Young? On Mon, Dec 3, 2012 at 3:14 PM, John Richard Sanchez youngupstar...@gmail.com wrote: This was a fun Job and very different from the normal commercial work I do. It was just me working from home and meeting with them on a weekly basis. Just wanted to share. https://vimeo.com/54680767 John PS If anyone needs and XSI artist in New York I am currently available. Will have a new reel with tons of new stuff in 2013. www.johnrichardsanchez.com
Re: reorder custom parameters
The problem with properties having to exist in a plug-in is that the moment you need any decent extent of dynamism in the layout you are SOL, so it's not really an option, and while you could get users to ignore errors, if you have automatic log compiling, summaries, monitoring etc (and we do) then you get false positives, and those are beyond annoying and enter dangerous grounds. Even if we accept that users will not panic and will remember what failures are tolerable and which ones aren't, purely for the sake of argument, because it ain't gonna happen, when you go to the farm/automation then you have to handle all those exceptions to erroring, and sorry, but that's just NOT going to happen as the risk for an excessively fault tolerant farm environment is never, ever, worth it. The only way around the lot is to have your own property cooking to create and destroy the error prone parts of the process on various events, but again, it will only be fine if your dynamism is at creation time, the moment you want truly dynamic layouts with proper garbage collection, there truly is no way out of it (without having hundreds of parameters stashed away hidden for when you might need them, with all the unacceptable added load that entails). In short: No, sorry, custom properties and persisting faulty layouts that appear to be working despite a polluted log are not conducive to a clean and healthy pipeline, they are the exact opposite, they are a damaging and muddying nugget in the pipe that usually turns cantankerous quick.
Re: OT_ Here is some work I did for Blue Man Group using Softimage and ICE
Ha! I think it would work with some mind altering substances. :) Thanks.:) On Mon, Dec 3, 2012 at 3:23 PM, Bradley Gabe witha...@gmail.com wrote: Nice work! Is it wrong that I was watching the video with the sound off while listening to Neil Young? On Mon, Dec 3, 2012 at 3:14 PM, John Richard Sanchez youngupstar...@gmail.com wrote: This was a fun Job and very different from the normal commercial work I do. It was just me working from home and meeting with them on a weekly basis. Just wanted to share. https://vimeo.com/54680767 John PS If anyone needs and XSI artist in New York I am currently available. Will have a new reel with tons of new stuff in 2013. www.johnrichardsanchez.com -- www.johnrichardsanchez.com
RE: reorder custom parameters
A custom property is a structured userdata intended to be placed within a specific scene context, such as on an object, cluster or other scene entity. They're useful for tagging objects and for identifying scene items. A sticky-note, of sorts. If you're using them for any other purpose, then you should re-evaluate why you're using them at all. We do very aggressive scanning and validating of data and have never run into such a problem of 'false positives'. Not even once. We use custom properties because they provide a way of tagging scene elements that is not prone to user error. No matter how hard the user tries, they cannot change the property's Type. Our assets have to function in software environments which need to make safe assumptions at runtime. Custom properties provide that safe haven. CustomParamSets do not as there is nothing in them you can depend on to get the same answer twice with certainty. All it takes is for a user to rename a CustomParamSet and all hell breaks loose. Often happens from routine operations such as duplicating or merging objects. Self installed Custom Properties are immune to that problem. The Layout of a custom property is separate from its definition. In fact, you can define the PPGLayout in a separate file and have it linked in using PPGLayout Logic. That alone likely avoids the problem you are now reporting. The external file supports both PPGLayout logic and PPGEvent logic. We have parameters that need to be populated by SQL queries as our assets can go years at a time without being touched. Our databases, on the other hand, go through frequent change as gameplay and other systems are frequently tweaked and honed. Tables often change in structure or get dropped and moved around. The custom properties in the scenes reading from those tables need to respond without having to be opened again. Having the PPGLayout dynamically driven from external file makes it possible as we merely have to update the external file and push the change into the workgroup. Based on past discussion, I am lead to believe you are using the ad hoc method putting logic at the bottom of your _Define callback in your custom properties to see if parameters exist or not, then dynamically stuff them in after the fact if they don't. I know some people advise that route, but I strongly disagree as it creates a scenario of complex uncertainties which leads to later instability. Try using the method I've long suggested that nobody seems to try - use events and replace the properties en masse on scene load. This involves a scene load event which scans the scene for custom properties, and compares versions of the properties in the scene vs. those installed in the workgroup. If the scene version is older, you re-instance the custom property into the scene, copy the old parameter values across to the new property then delete the old property. This ensures data is up to date and synced with the latest state of the property. Yes it is a little work to set it up, but it's significantly more reliable and easier to trouble shoot because the rules are simpler, centralized, and predictable. It also allows you to extend the system for other options such as conditional updates, deprecation, or conversion from one property type to another. Whatever problems you're experiencing, we have never encountered them here and we lean on custom properties very heavily. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane Sent: Monday, December 03, 2012 3:06 PM To: softimage@listproc.autodesk.com Subject: Re: reorder custom parameters The problem with properties having to exist in a plug-in is that the moment you need any decent extent of dynamism in the layout you are SOL, so it's not really an option, and while you could get users to ignore errors, if you have automatic log compiling, summaries, monitoring etc (and we do) then you get false positives, and those are beyond annoying and enter dangerous grounds. Even if we accept that users will not panic and will remember what failures are tolerable and which ones aren't, purely for the sake of argument, because it ain't gonna happen, when you go to the farm/automation then you have to handle all those exceptions to erroring, and sorry, but that's just NOT going to happen as the risk for an excessively fault tolerant farm environment is never, ever, worth it. The only way around the lot is to have your own property cooking to create and destroy the error prone parts of the process on various events, but again, it will only be fine if your dynamism is at creation time, the moment you want truly dynamic layouts with proper garbage collection, there truly is no way out of it (without having hundreds of parameters stashed away hidden for when you might need them, with all the unacceptable added load that
Re: reorder custom parameters
I thought we WERE talking layouts here, otherwise why would you even remotely care about re-ordering parameters? Of course if you're just adding tags, go ahead, do whatever, it doesn't matter then because if a user has to see tags you have a mistake somewhere in the design or are not providing the right tools for inspection. You might as well add blobs at that point though, they are much better insurance against user mistakes and provide clear entry and exit states, and the price of ser/deser is negligible even on large amounts of them, and at that point you're at least not limited in data types anymore. I don't remember the past discussion you mention, but no, I don't like define callbacks to begin with, and sure don't use them for layouts :) I have experimented with a number of solutions over the years, including exploiting the current system with events and file monitoring, but in the end it's simply too damn limited. All you point out about files makes sense in the context you describe it in, but you're still up a creek without a paddle if you need any dynamism to the layout, whcih is what I'm referring to. PPGs (which front custom properties, unavoidably) are THE only inbuilt mechanism in XSI to offer interfaces that persist with the scene, if you need them to be created on the fly and respond to user interaction, what you describe is simply impossible in Soft, whereas it is in some other applications. You are offering a very limited subset of what a custom property is in the first paragraph, as you are limiting it to a collection of unchanging (as far as the user interaction is concerned) parameters, and something else that doesn't address the problem I'm talking about in the third. I'm now confused about what we'd be discussing here :) Replacing or tweaking parameters through events is possible, and has been done, but again it doesn't offer a thing when it comes to user interaction, and the cost can be exorbitant. Doing it sparsely like on scene load or save is far from enough, and doing it more frequently like on selections is simply going to lag the user into ripping their hair out. It's not that people haven't tried it because they don't like the idea, many have tried it and found it simply insufficient. As for names, as long as your tag has an ID bundled it's easy to repair any damage for a minimal cost, as a fall back or as a manual process. I am officially confused to hell now though about what we're trying to shed some light on, so I'll probably bow out of this :) On Tue, Dec 4, 2012 at 11:37 AM, Matt Lind ml...@carbinestudios.com wrote: A custom property is a structured userdata intended to be placed within a specific scene context, such as on an object, cluster or other scene entity. They’re useful for tagging objects and for identifying scene items. A sticky-note, of sorts. If you’re using them for any other purpose, then you should re-evaluate why you’re using them at all. ** ** We do very aggressive scanning and validating of data and have never run into such a problem of ‘false positives’. Not even once. We use custom properties because they provide a way of tagging scene elements that is not prone to user error. No matter how hard the user tries, they cannot change the property’s “Type”. Our assets have to function in software environments which need to make safe assumptions at runtime. Custom properties provide that safe haven. CustomParamSets do not as there is nothing in them you can depend on to get the same answer twice with certainty. All it takes is for a user to rename a CustomParamSet and all hell breaks loose. Often happens from routine operations such as duplicating or merging objects. Self installed Custom Properties are immune to that problem. ** ** The Layout of a custom property is separate from its definition. In fact, you can define the PPGLayout in a separate file and have it linked in using PPGLayout Logic. That alone likely avoids the problem you are now reporting. The external file supports both PPGLayout logic and PPGEvent logic. We have parameters that need to be populated by SQL queries as our assets can go years at a time without being touched. Our databases, on the other hand, go through frequent change as gameplay and other systems are frequently tweaked and honed. Tables often change in structure or get dropped and moved around. The custom properties in the scenes reading from those tables need to respond without having to be opened again. Having the PPGLayout dynamically driven from external file makes it possible as we merely have to update the external file and push the change into the workgroup. ** ** Based on past discussion, I am lead to believe you are using the ad hoc method putting logic at the bottom of your _Define callback in your custom properties to see if parameters exist or not, then dynamically stuff them in after the fact if they don’t. I know some people
RE: reorder custom parameters
It started as a layout discussion of how to reorder parameters, but some of the other replies were coming in and stating to use customparamsets for other things which custom properties were better suited. When I saw your reply I interpreted it along those lines. Hence the reply as stated. If you all you care about is dynamic layout, I still advise using the custom property over the customparamset because you can use an external layout file with a custom property to abstract the problem away from being embedded in the scene. This gives you full control over the layout of the property page including ordering of parameters and definition of PPGEvents, if needed. Parameters can be reordered at any time and take effect the next time the custom property is inspected or refreshed. That's a better solution than customparamsets as was otherwise suggested which essentially have no PPGLayout other than through the use of .preset files (which have since been deprecated), or using the workaround hack of dynamically generating all the layouts every time a scene is loaded. That is more maintenance and prone to problems. I do not disagree the Softimage layout options are quite limited, but at the same time they can respond to user input on the fly if you code as such. I do not understand what problems you're encountering in this respect. If you want a widget that isn't offered, OK, I see that. If you're missing a more elegant PPGEvent callback, OK I can see that. But I don't understand these other errors you're getting with monitoring and running farm automation with false positives. Why would UI be involved in that stuff in the first place? That is my question to you. Matt From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Raffaele Fragapane Sent: Monday, December 03, 2012 6:07 PM To: softimage@listproc.autodesk.com Subject: Re: reorder custom parameters I thought we WERE talking layouts here, otherwise why would you even remotely care about re-ordering parameters? Of course if you're just adding tags, go ahead, do whatever, it doesn't matter then because if a user has to see tags you have a mistake somewhere in the design or are not providing the right tools for inspection. You might as well add blobs at that point though, they are much better insurance against user mistakes and provide clear entry and exit states, and the price of ser/deser is negligible even on large amounts of them, and at that point you're at least not limited in data types anymore. I don't remember the past discussion you mention, but no, I don't like define callbacks to begin with, and sure don't use them for layouts :) I have experimented with a number of solutions over the years, including exploiting the current system with events and file monitoring, but in the end it's simply too damn limited. All you point out about files makes sense in the context you describe it in, but you're still up a creek without a paddle if you need any dynamism to the layout, whcih is what I'm referring to. PPGs (which front custom properties, unavoidably) are THE only inbuilt mechanism in XSI to offer interfaces that persist with the scene, if you need them to be created on the fly and respond to user interaction, what you describe is simply impossible in Soft, whereas it is in some other applications. You are offering a very limited subset of what a custom property is in the first paragraph, as you are limiting it to a collection of unchanging (as far as the user interaction is concerned) parameters, and something else that doesn't address the problem I'm talking about in the third. I'm now confused about what we'd be discussing here :) Replacing or tweaking parameters through events is possible, and has been done, but again it doesn't offer a thing when it comes to user interaction, and the cost can be exorbitant. Doing it sparsely like on scene load or save is far from enough, and doing it more frequently like on selections is simply going to lag the user into ripping their hair out. It's not that people haven't tried it because they don't like the idea, many have tried it and found it simply insufficient. As for names, as long as your tag has an ID bundled it's easy to repair any damage for a minimal cost, as a fall back or as a manual process. I am officially confused to hell now though about what we're trying to shed some light on, so I'll probably bow out of this :) On Tue, Dec 4, 2012 at 11:37 AM, Matt Lind ml...@carbinestudios.commailto:ml...@carbinestudios.com wrote: A custom property is a structured userdata intended to be placed within a specific scene context, such as on an object, cluster or other scene entity. They're useful for tagging objects and for identifying scene items. A sticky-note, of sorts. If you're using them for any other purpose, then you should re-evaluate why you're using them at all. We do very
Getting Vertex positions from a Hair primitive with python
Hi Can anyone share the method to accomplish this (if it's even possible :p ) please? -- Kind Regards, Jared Glass | Technical Lead
