I'm looking at the Collada format also.
The idea would be to get an exporter that retains the 3D model
as close to what was built in 3D Max.

By playing around I pretty much figured out how the Models are built.
How to set the 'hidden' value,
and how the cfg# nodes are done and such.

All this is done before exporting the Unit from 3D Max.
:yep:

And I'd say it was done this way before switching to the Granny system.
But it went through thier exporter instead for conversion to dat files.

:yep:
The format allowing as much as possible to realise features of game and 3ds Max...
But if you plan to use only 3ds Max, for what to you the intermediate format is necessary? :hmmm:

The .FBX format seems to be a viable export option for cross compatability.
:hmmm:
The SDK is free also.

The .obj format is probably manditory for most people though.

So proposed formats could be:
.obj
.3DS
.FBX
.X
.dae

Multiple export options is a must as I see it.

After testing each format I believe the .3ds format would loose the least
amount of information on export from a GR2 file.

So that narrows it down to 2 formats I'd like to see.
.3DS
.OBJ

I would stop any attempt to decode the GR2 format, as with other games in the past RAD Game Tools the owner of Granny starts legal action against modders:stare:

privateer knows his way around the block. Just sit back and watch a genius at work. :up:

Are you sure?

3DS is limited in that it's strings can only hold up 16 characters iirc (object names, material/texture names, etc) unless you use an extension, which makes it non-compatible to alot of 3D-programs/converters, something you'd want to prevent. It's why I dropped it for S3D.

OBJ is a big no as far as I am concerned because you have the same problems again with multiple uvw channels. What I built into S3D clearly is a hackjob and not a supported method of import by ANY 3D program. So you end up doing alot of handywork again to merge all channels.

Clearly, the only viable formats are those that support multiple uvw channels, and skeletal, mesh, matrix and texture animations (or at least a couple of these) and (VERY important!) meta data (stuff like visibility flag., matrix transforms, controller data or custom data)
The ones that come to mind are already mentioned:
- X (although I think it is officially dropped in favor for FBX)
- FBX
- Collada

[edit] But yea, in the end, you will hit a (legal) wall with regards to GR2. Unless we get an official 'endorsed' importer/exporter, best to forget about it, and hope full (legacy) DAT-support will be enabled in a future patch.

Even more, it can't store objects with a higher vertex/poly count than 65536.

This will not happen. With which a big part of SH5 will not remain modifiable.

If someone is working on a Tool,
they have not stated so in this thread.

Most of the discussion here is hypothetical at this point.
It's a way to pass information about a POSSIBLE tool,
Without all the whineing and crabbing at the Devs
found in so many other threads.

I've stated many times my concern about Legal issues.
I've also visited every site I can find that concerns GR2 file structure.
I've found no concrete evidence that RAD Games is concerned
much about past attempts.
There's alot of code out there that could be removed at thier demand
but is not.

If attempts were stopped in the past?
Most seem to have been stopped by the Game Developers
that use RAD Games Tools.

@skwasjer,

Thanks for the information.
I was not aware of the limitations in the different formats.
It's a learning process for me at this point.
:)

I don't sure if it's usefull or legal but...

http://aoe3.heavengames.com/cgi-bin/...f=14,36458,,10

:salute:

I sincerely hope that this is true and all is okay with your work on the legal front. I'm having a bit of fun playing the arcadey goals of SH5 until someone gets a real campaign worked up, but I'm quickly losing interest due to the lack of ships out there. I'm getting tired of sinking the same 4 ships over and over.

Well true I forgot about that, but this wasn't a requirement for SH3/4 as DAT had same limit :)
Not me :)
Perhaps you're right. S3D could have been stopped by Ubisoft too, for legal reasons. Still, the choice of GR2 is a wise choice from a developers perspective, but the fact that it's not an open format/SDK makes it very problematic to support by a community. DAT still isn't fully known after 5 years (although nearly there, just only that one byte in model chunk, and skeletal anim related stuff). And here we are now, we need to start over completely from scratch. It's not just how to decode it, the problem is games/3D are increasingly complex and thus more data needs to be figured out... That's a major step back without developer support.

You know, if only just they'd provide us with the header files and export some entrypoints, they don't even need to add support to Goblin...
[edit] I know about the granny DLL, but I rather not use that.

to get the gr2 tools better known...i might can provide the dev-tools from rad to the ones, who need it in the hope to learn about/from it. just drop a pm. i got them from a friend of mine, but can not use them. they are only code files which need to be linked/added with the software you are working with. never understood how to do this. but i am no coder guy...maybe one of you is.

:salute:


and...by the way:

http://gr2decode.altervista.org/docs.html

That's exactly what I asked (calling granny2-functions isn't the problem, I've already done that, but knowing the exact parameters/structures is, even with the current available public info):

You know, if only just they'd provide us with the header files and export some entrypoints, they don't even need to add support to Goblin...

The question is, is it legal... If it is, and I can have it, that would be the only trigger for me to actually work on support for S3D. Without it, nuh-uh...

there are tools one can use to find out what parameters are needed and what the parameter types are (from Microsoft of all people :o).
Is it legal? Why not? Here's a case in point:

The microsoft word format when Word was first released included no documentation on how to 'read' the file Word created. So with a little reverse engineering third party companies discovered how the file was 'created' and began making applications that could read and write word documents. Did you see Microsoft getting all upset about this? No.
And from the DRM laws enacted by this country (USA) it is not illegal to reverse engineer a file to discover how to make your application compatible with it or to discover undocumented functionality.

Over on the Ubisoft forums they asked for questions to ask the devs. My question was if such tools as you're talking about will be released to players. Lets hope they answer it! :)

Seriously, now you are being funny. Name one tool that can export a header file (iow. functions/parameters/constants/typedefs/etc) from a native DLL, I'd buy it instantly! I can't wait!

All I want is to NOT have to open a hexeditor, debugger, or other analysis tool and waste hundreds more hours. I want an API to use that does the lowlevel binary legwork for me. There's already some good info available, but it's not good enough for me.

Call me lazy :O:
Not much else to do for me than wait :D

There is tool "undname.exe" to view undecorated names.

http://msdn2.microsoft.com/en-us/library/5x49w699.aspx
http://msdn2.microsoft.com/en-us/library/b06ww5dd.aspx

http://www.codeproject.com/KB/cs/Vis...px?msg=3414144