Page 17 of 45

Re: XSI ZETools

Posted: Sun Apr 29, 2012 5:27 am
by ANDEWEGET
@minilogoguy: Yeah, well, the videos are 'realtime' so as you can see it didn't take long anyways. The idea with the keys is nice, the next time I'm enveloping something I'll try that.

@tirpider: Yes, that's the idea. The tweaking still takes a lot of time because the volumes aren't very precise(only boxes and spheres)so it might miss points here and there which you then have to track down.

I've been thinking about how I could do cloth. I'm somewhat stuck on the way to extract the constraint data from XSI... The other feature I'd like to include still is stuck on those Diet Dr. Pepper CRCs.

Re: XSI ZETools

Posted: Sun Apr 29, 2012 6:24 am
by tirpider
re:CRCs
They are hard to nail down.
I know why they are CRCd.
It's to make the bone reffrence a predictable number of characters long, but still remain unique.
Makes it quicker for the engine to flip through them.

I'm flat stumped on the algorithm, though.
I was sure it would be whatever default/built-in functions XSI had.
Perhaps the developers had a seperate tool or custom plugin to assist with building the animations.

Re: XSI ZETools

Posted: Sun Apr 29, 2012 8:55 am
by ANDEWEGET
These were professional programmers and they wrote their own engine. So they could just have written a CRC tool/module with their own algorithm. They had to be able to check/create CRCs in the engine and all of the .msh tools, too, so it couldn't really have been something built into XSI(I didn't find anything anyways).
I still wonder why they used CRCs only in the animation chunks and not for PRNT, cloth collision stuff etc... If it weren't for those I could have implemented animations weeks ago. Fetching the actual animations isn't very difficult as it seems.

Re: XSI ZETools

Posted: Sun Apr 29, 2012 12:17 pm
by minilogoguy18
^I always remember though fred saying that the engine itself was built around XSI and the .msh format was supposedly pretty close and based off of the .xsi format.

Back when SWBF2 came out I used to talk to him regularly through IM.

Yeah main thing that makes using a simple couple of key frames to help animate is that you can pose the model, use the weight painter to tweak everything so that the deformation is more realistic then just change the timeline so that the model snaps back to the base pose. I do this all the time when working on JA characters.

Re: XSI ZETools

Posted: Fri May 04, 2012 8:19 am
by ANDEWEGET
ANDEWEGET wrote:Yeah, that was noticeable while writing the exporter. I didn't compare a lot to .xsi but at the first glance there were similarities. For example this .xsi template:

Code: Select all

SI_Scene Scene { 
   "FRAMES", 
   1.000000, 
   100.000000, 
   29.970030, 
}
pretty much exists in the same structure in .msh files(SINF chunk).

The .xsi ASCII-format definitely doesn't use CRCs though. I couldn't really find any information on the binary version... Maybe I can find something in the Crosswalk SDK.
Does anybody know if shadowvolumes with the shadowvolume parameter in XSI and exported with the Pandemic Tools are 'better'(more efficient?) than the ones created by modelmunge? If they are I'll add them to the exporter.

Re: XSI ZETools

Posted: Sat May 05, 2012 11:00 am
by DarthD.U.C.K.
do you mean the shadowvolumes created with the highresshadow line in the msh.option?
selfmade shadovolumes are much better performance-wise (and less buggy). id only use the highresshadow if there is no way to get the model properly into xsito make a shadowvolume by hand.

Re: XSI ZETools

Posted: Sat May 05, 2012 1:20 pm
by ANDEWEGET
I believe I mean those... If that's the only way to let model munge create the shadow then I definitely mean those.
I just found out about the SHDW chunk, I don't really understand the system how it stores the shadow mesh geometry yet but that shouldn't be a problem.

Re: XSI ZETools

Posted: Sat May 05, 2012 2:49 pm
by The Nasal Abyss
ANDEWEGET wrote:I believe I mean those... If that's the only way to let model munge create the shadow then I definitely mean those.
I just found out about the SHDW chunk, I don't really understand the system how it stores the shadow mesh geometry yet but that shouldn't be a problem.
The engine just recognizes the geometry that has "sv_" before the name and just makes it the shadow volume. At least, I think that's what it does.

Re: XSI ZETools

Posted: Sat May 05, 2012 5:19 pm
by ANDEWEGET
AFAIK there are two ways to get shadows ingame. One way is to name a model 'sv_*', then the engine creates the shadow from the generic geometry chunks which nearly every model has. Dunno if you need the hirezshadow command in the .option for it though...
The other way is to assign a parameter called 'shadowvolume' to a model. The pandemic exporter then exchanges the usual geometry chunks for a SHDW chunk.

I'm not really sure how exactly the first option works anymore though. It's a long time since I exported something with the pandemic exporter.

Re: XSI ZETools

Posted: Sat May 05, 2012 5:52 pm
by tirpider
At first, I thought the SHDW was used for non animated shadows, because you find it in a lot of the hover and flyer vehicles.

But now, I'm digging around in the TCW msh's and all the actor shadows are SHDW.

Haven't even begn to parse the format yet, but without looking I bet it's going to be verts only, with no uv's, normals, or weights. A shadow wouldn't need all that, eh?

Re: XSI ZETools

Posted: Sun May 06, 2012 4:39 am
by ANDEWEGET
According to 'the tool' it's a list of verts followed by a list of edges. I tested it with a cube,
the vert list had 8 vertex positions(! POSL would have 24),
the edge list had 24 entries with 4 numbers each. The edges are weird. Every 4th entry is the max value a short can hold(65535, I assume to indicate a new edge). The indices which should define edges, even though it only stores 8 vertices, range from 0 to 23(in this case). When compared to the sample/node indices which the exporter usually uses the indices sometimes define a triangle(ie 0, 1, 2) and sometimes they just define one edge(0, 1, 0)...

Re: XSI ZETools

Posted: Fri May 11, 2012 1:29 pm
by Webster27
When I try to export my model I get this error which is probably caused by me, because I forgot to do something(still a big big noob in XSI)
Hidden/Spoiler:
# ERROR : Traceback (most recent call last):
# File "<Script Block >", line 481, in MSHExport_Execute
# flags = retrieve_msh_export_flags()
# File "<Script Block >", line 767, in retrieve_msh_export_flags
# import andecore.config
# ImportError: No module named andecore.config
# - [line 766 in C:\Softimage\Softimage_Mod_Tool_7.5\Addons\XSIZETools\Application\Plugins\XSIZETools.py]
# ERROR : OLE error 0x80020101
Application.MSHExport()

Re: XSI ZETools

Posted: Fri May 11, 2012 1:50 pm
by ANDEWEGET
ANDEWEGET wrote:You've unpacked the .7zip into the wrong directory.
Yours is in: C:\Softimage\Softimage Mod Tool\Addons
Should be in: C:\Users\User\Autodesk\Softimage Mod Tool\Addons

Re: XSI ZETools

Posted: Fri May 11, 2012 2:07 pm
by Webster27
There is no Addons Folder ìn that Directory, should I just create one ? :|

Re: XSI ZETools

Posted: Fri May 11, 2012 2:15 pm
by THEWULFMAN
Yep. Go ahead and create one.

Re: XSI ZETools

Posted: Sat May 12, 2012 4:54 am
by Webster27
Thank you Ande and Wulf ! It worked ! :bowdown:

Re: XSI ZETools

Posted: Tue May 15, 2012 12:09 pm
by ANDEWEGET
Does anyone know if it's possible to export multiple animations in one .msh? Looking at the CYCL chunk it definitely seems possible.

Re: XSI ZETools

Posted: Tue May 15, 2012 12:21 pm
by Marth8880
What, with your tools or the Pandemic Tools?

Re: XSI ZETools

Posted: Tue May 15, 2012 2:09 pm
by tirpider
The TCW player models look like they have all the animations in the same msh.
Different thing going on with them, I know, but the file format is the same.

Re: XSI ZETools

Posted: Tue May 15, 2012 2:36 pm
by ANDEWEGET
With the Pandemic Tools. The ZETools can't export animations and I believe I would know if it did... :D
If it's possible I could add support for multiple animation cycles. I think it's best to use one .msh per animation. This way you don't have to export all animations in the .msh again if one is off.
I'd have to read up on animation actions in XSI etc tho... So maybe I'll just go with one cycle per .msh. ;)