|
Hi,
We've just finished a job for the new www.vw.co.uk website. We've scanned the whole range and rendered out all the isolated elements necessary to allow people to configure their own cars. i.e. Every variation of every model in every paint colour with all the wheels, fabrics and optional extras that go along with it.
As there will be new models and ongoing additions to what exists already, I wanted to find a way for the producers and animators/modellers to have access to overviews of what each Model is made up of. This would also allow some automation in setting up new models. i.e. The Producer can enter all the data for the car & I can read it into XSI to create the correct setups.
Once you know what should go into a car model, how many trims, paints, engines etc. It's not too difficult to set up all the Passes, Partitions, Groups & hierarchies that should be filled by the geometry that will be created. It's just a pain doing it manually and it's better to have an automated naming system so that new people on the project won't get too confused and there's less chance of error.
It seems that a format like XML would hold all that information quite neatly and be quite accessible from inside and outside XSI. The client is also using XML at their end to control the website content so it would be nice to have some extra synchronicity with them, matching tag names and XML structures.
I was just wondering whether it's a sensible idea to import an XML sheet using Python, and then put that information into a Custom Model for flexibility within the script. If new data is added, then the Custom Model could be written back out as an updated XML file that could be read again by the producers. Creating Custom Models doesn't look like the most straight forward route right now but I was curious to know if it's worth getting my head around.
Or will I just end up over-complicating things (like my life).
Adam.
(Already married and she thinks that it's the cat that smells.)
________________________________
From: owner-xsi(at)Softimage.COM on behalf of Raffaele Fragapane
Sent: Thu 14/02/2008 13:05
To: XSI(at)Softimage.COM
Subject: Re: Scripting - Python, XML & Custom Models
Me and Nick Petit had a pretty amibitious design draft and a (fully working) first implementation of the backend going (on a fairly large scale/scope too) that would run databse-less through smart data inheritance.
The only downside to it is it will do your head in, and it takes a fair few weeks to design and structure efficiently before you can even think of writing the first line of code.
Well... that and the fact it WILL need regular updates and maintenance, it's not a one off project, it's an ongoing inferno that will destroy your private life and make your pets hate you, not to mention girls will smell you for the full nerd you are from miles away after only two days into designing file formats, so you'd better be married already and your partner'd better have no sense of smell, or it's a divorce.
What is the intended use, scale and userbase of the project?
On Thu, Feb 14, 2008 at 12:35 PM, Bernard Lebel <3dbernard(at)gmail.com> wrote:
The big con is performance.
I used XML to read and write things like
- list of all models in the scene with their srts
- passes (including render options, shader stacks, partitions,
overrides, partition members, etc)
- element arrays (uvs, envelopes, etc)
- materials
- animation (fcurves, expressions)
I think using a scripting language for element arrays is a really bad
thing for performance. This is awefully slow. C++ is the only way to
go if you don't want to use presets.
Personally I'd avoid using XML for animation completely. Presets and
mixer files are perfectly suited for this job, and it's very fast and
very reliable. UNLESS you intend to move animation across different
packages. In this case, C++ is unchallenged king of the hill.
Another con is disk space. You might want to compress these files.
As for pros, it's an industry standard so it can be read by most
programming languages, it can be displayed as a tree in browsers
(although always initially expanded), it can be sent easily over http,
it's highly customizable. I'm sure many more advantages can be brought
up. For instance one could export "rigs" that way. That is, a map of
all the objects making the rig, the constraints, expressions, etc. One
could conceive building a library of separate XML files that each
contain a portion of the rig, and they could be used as building
blocks for creating rigs in a highly standardized pipeline.
One more thing. I don't know what you intend to store into XML files.
But if you are looking to create some sort of database for your shots
and assets, with things like start frame, end frame, shot content,
model locations, etc, you definitely should consider going with MySQL
instead (or some similar form of relational database server). That's
the real deal. Such a database-driven pipeline opens the door for lots
of really powerful tools.
Python has a nice module called MySQLdb which makes transactions easy
(although I don't know what's the latest compatible version). Also you
could send requests to php scripts that deal with the MySQL
transactions if you don't want to code it in Python. In this case,
check the urllib, httplib and similar HTTP modules.
The drawback with MySQL is that if someone not using XSI has to make
use of it, you have to create a web interface.... and functional web
interfaces are time-consuming to create.
Cheers
Bernard
On Thu, Feb 14, 2008 at 6:45 AM, Adam Seeley <Adam.Seeley(at)vtr.co.uk> wrote:
> Hi,
>
> I'm looking at using XML for keeping track of Data. Python seems to be the language to use because of the built in XML handling.
>
> It seems like turning XML data into some sort of Custom Model structure in XSI to help navigation and exporting updated data might be a good idea.
>
> Wondered who's been down this road and what the pro's and con's might be to this approach.
>
> Thanks,
>
> Adam.
>
>
>
>
>
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.4 - Release Date: 12/02/2008 00:00
<<winmail.dat>>
|
