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: [email protected] [mailto:[email protected]] On Behalf Of Raffaele Fragapane Sent: Monday, December 03, 2012 6:07 PM To: [email protected] 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 <[email protected]<mailto:[email protected]>> 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 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Raffaele Fragapane Sent: Monday, December 03, 2012 3:06 PM To: [email protected]<mailto:[email protected]> 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 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. -- Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!
