[REL] S3D - Silent 3ditor

[SquareSteelBar]

Originally Posted by sober

thanks for the best silent hunter mod tool ever

Agree...

Originally Posted by skwasjer

...I won't be actively developing it either for at least a few months.

Again:

[skwasjer]

For those that have the automatic update notification disabled, or work with an older version of S3D. Let me know if the new features work out ok... Have fun!

Version v0.7.1 - Download link in main post (or follow link in footer to my site)

New

• Context menu of Dat-editor extended with new menu items. The Cut/Copy/Paste items are still not implemented though. This will hopefully be done soon.
• You can now add 'fully known' chunks directly from one of the menus (context or main menu). The newly created chunk will have a randomly generated id (if it supports an id field), but other than that is fully uninitialized. New chunks are inserted right after the selected chunk, but are NOT automatically parented to parent chunks.
• Added a menu option to replace the current id of a chunk with a new random id. Child chunks will have their parent id fields updated as well.
• Added a PayPal button. If you feel inclined, you can support development of S3D with a donation.

Changed

• Properties node label now displays the actual name of the controller data, instead of the generic term 'Properties'. It will also indicate whether or not it is linked to a valid controller chunk, by displaying both the parent name as well as the local name if they are different. Ie. if you link a Float properties chunk to a ShipWake controller chunk, the label would be !ShipWake! - Float, to indicate the incorrect relationship.
• Changed controller definition of SH3 controller: ShipWake/StartParameters/LeftVertex/StartPosition (also for RightVertex) from Vector2 to a custom type Vector2XZ. (thanks Mikhayl)

Fixes

• Fixed bug that occurred when importing raw chunks that don't contain a header (thanks keltos01). This bug was introduced in v0.7.
• When assigning a new 3D model id to a node, the model was not moved correctly in the tree hierarchy.
• Embedded images could be parented to any chunk. They can now only be parented to materials and illumination chunks, and otherwise will always be placed in the root.
• A couple of minor issues fixed.

[DrBeast]

It's up to 0.7.1 already? Wow...time to upgrade my 0.5.4 version I guess
Truly, a mere "thank you" is not enough for the outstanding tool you've created.

[Subject]

I have this "strange" thing...

When opening scene in S3D, I get this:

...but when opening in MiniTweaker, scene.dat is fine?

The scene.dat is from Reece's "Combined SH4 Scene for SH3 version 3" and I'm using 8k Env Scene 2.6
http://www.subsim.com/radioroom/showthread.php?p=831674

Just a FYI... please don't run away!

[skwasjer]

I can tell you that that scene.dat file is corrupt. Someone screwed up the EnvSim data. S3D shows you it is unimplemented, but it just can't read some data somewhere in that controller.

[edit] I've seen this happen before and it almost always due to use of MiniTweaker with incorrect tweakfiles. The ROW mod had a similar error at one point, and some other environmental mods have produced similar errors, all due to outdated tweakfiles.
[edit2] The game is very forgiving when data is missing or incorrect, in which case it uses some sort of default or uninitialized value. S3D isn't and for a reason (otherwise, you'd never know you had an error).

[skwasjer]

Right, I'm going to let of some steam.

[Rant at the 3D industry]

So ok, close to 8-9 months ago, I started researching a good 3D finterchange format I could use for this game.

So, I have been busy reading, reading, debugging, writing test code, until 11-2007. After months of research I finally ended up with COLLADA but even that had limitations and is still giving me headaches today. And then I read the bad news that FeelingSoftware is dropping it's development on the free plugin library (which does alot, but is still incomplete). I'm at the point where I consider dropping this format as well because it just can't do what I need. I have to move on looking for alternatives (yea right!), or even just forget about multi-UV import/export. The alternative not-so-nice approach is to export models x times, where x would be the number of channels. You'd basically end up with 2 exported files for a model with 2 UV-channels. Same for import. There are other problems involved here that I desperately seek to avoid...

I've read hundreds of topics on 3D formats by now, and it boils down to a format war in the industry. Everyone is keeping their own proprietary format, and they refuse to adopt a standard which does all. The standards that are there, are hard to implement, or incomplete or not widely supported... And they are a 'standard' from a select party, not the entire industry.

The formats that do what I need for this game are so difficult, miss features or closed/undocumented it is becoming very frustrating. I have manually debugged close to a dozen or so formats by now (compare that to 2 formats: DAT/SDL). I could have finished this 6 months ago if there was a good public format available. Oh yea, or if I could buy an SDK ($$$) for one of those proprietary formats... Or ask Right Hemisphere/Feeling Software, or some other company to do it for me ($$$)...

I don't understand for the love of god, why today - 2008 - there still is not one good 3D interchange format available that everyone supports. If you know of one (mesh,material,multi-uv,bones/anims, and the needed support for Diffuse/AO/Spec/Bump maps) , PLEASE TELL ME! I've read many complaints from many other 3rd party or just 3D enthusiast developers, it's just ridiculous...

Looking into U3D format now for the past week. It looked pretty good at first, but now I see it's yet another one of those. Difficult, and missing AO/Bump support, and it may likely die as a format... Bleh.

So here I am, with a decent 3D import/export API I made myself to attach exporters to, but no good format to hook into.


[/end rant]

So, what now? Well, I do have some tricks up my sleave so I'll head back into my dark corner and start working on it, and see where we end up. I WILL finish it, ffs...

[DeepIron]

Crap! I thought your Collada export was working really well too! I've been exporting models, checking for inconsistencies and such and you've really done an incredible job. Not to mention the Collada .xml output is fantastic for post-processing and conformity checking... So...

How about .fbx? AutoDesk has a freely available SDK that I "think" might solve your multiple UV issue and others. It incorporates support for Collada 1.4, .obj and .3ds formats as well...

At the bottom of the page:
http://usa.autodesk.com/adsk/servlet...112&id=8224926

They have very good SDK docs as well.

A couple of years ago I downloaded the SDK for a project that I was involved with and it looks good. Unfortunately, the project got scrapped (as they often do it seems) and I dropped my programming part of it.

[skwasjer]

Originally Posted by DeepIron

Crap! I thought your Collada export was working really well too! I've been exporting models, checking for inconsistencies and such and you've really done an incredible job. Not to mention the Collada .xml output is fantastic for post-processing and conformity checking... So...

You're right on that part. Collada is a good format and it basically supports all that I need, but the support by other programs/plugins has still not matured enough. While the S3D export seems to work fine (and can be imported by most other programs), even Max fails to read in the materials properly (and thus loses connection to the map channels). Also, if I manually correct it, the model that I get back after an export from other programs is missing the data I need, and again it's the uv-channels.

Originally Posted by DeepIron

How about .fbx? AutoDesk has a freely available SDK that I "think" might solve your multiple UV issue and others. It incorporates support for Collada 1.4, .obj and .3ds formats as well...

At the bottom of the page:
http://usa.autodesk.com/adsk/servlet...112&id=8224926

They have very good SDK docs as well.

A couple of years ago I downloaded the SDK for a project that I was involved with and it looks good. Unfortunately, the project got scrapped (as they often do it seems) and I dropped my programming part of it.

I've looked into FBX a while ago (back in sept/okt) I guess, and decided not to use it although I can't remember exactly why anymore. But likely also problems with uv's. I know for a fact (by experience longer back) it's a good format, but I didn't just drop if for no reason. Maybe I'll have to revisit it...

Ah well... I probably am going for a quick-n-dirty approach first now just to get import done soon (using .obj or something). I'll then satisfy everyone's need to at least be able to import models, be it tedious to do and maybe without multi uv-support first. At least then I have some rest to try other formats.

[DeepIron]

Ah well... I probably am going for a quick-n-dirty approach first now just to get import done soon (using .obj or something). I'll then satisfy everyone's need to at least be able to import models, be it tedious to do and maybe without multi uv-support first. At least then I have some rest to try other formats.

Understandable... best not to lose too much "momentum" over this... FWIW, I'd have to say .obj would be a logical choice at this point... simple format and easily converted by just about every modeler out there...

However, I'd say you're doing a smokin' job of it and I'm sorry for your setback...

BTW, I've been using MeshLab http://vcg.sourceforge.net/tiki-index.php to read and convert your .dae files. Works quite well for the geometry but doesn't load the textures out of the .dds files. I think if I separated the textures and created new .dds files, it might work...

[ref]

skwas, you've pm.

Ref

[skwasjer]

You do too

[skwasjer]

Originally Posted by DeepIron

Understandable... best not to lose too much "momentum" over this... FWIW, I'd have to say .obj would be a logical choice at this point... simple format and easily converted by just about every modeler out there...

However, I'd say you're doing a smokin' job of it and I'm sorry for your setback...

What pisses me off even more is that I just should have listened to myself. Almost one year ago, just after I started this project I talked to DivingDuck (now part of GWX team), and said I was going to do it the way I described above. We talked about it and it was a good idea. It was going to be tedious because of manual postprocessing was required in a 3D studio, but it would work.

But I had so many other features and general functionality to develop, I postponed model support for a few months. Then, I said, let's find a better 3D format that does 'all'. And well, here we are now. Damn 3D industry.
If I just followed my initial idea, that quick-n-dirty approach would have been in S3D for at least 6-7 months...

The upside is, I have obj-exporter/importer code lying around from a project a few years back when I made some tools for other games (it already has features to reverse face winding, specify up-vector, and supports various other options). It will need a bit of a facelift, but it won't take very long from now. I promise...

[DeepIron]

Well bro', as they say, hindsight is 100%... I've found myself in the same predicament, many times when I shoulda' listened to that "little voice"... But hey, the day we stop learning is the day they lay us on our backs and throw dirt in our faces!

On the upside, at least you have some code layin' around that could save you some further head-banging!

The community has faith in you Skwasjer and we know it's only a matter of time.

[skwasjer]

So ok, the obj-model exporter is working, and am now working on sticking in the obj-importer. I will leave the DAE exporter in as well for a while at least, and maybe I can improve it later as well and eventually maybe even the dreaded dae-importer.

I've thought some more on the whole multi-uv issue and my idea to work around this (as far as importing) will be the following:

• You build your model in your 3D studio or have reconstructed one from an import from the game.
• You make it with multiple channels, so it renders the way you want. This can be with diffuse, AO, spec, bump, custom lights, camera's, whatever you want. You have set up materials accordingly.
• Before exporting from your 3D studio, you clone the model 'n' times in the same scene, where 'n' is the number of unique map channels. You can move the clones away from the original model, and it doesn't really matter where you place them (just keep them visible).
• Now, for each cloned model you 'copy' the required UV channel to the 1st channel.
• The 'name' of each clone must be identical to the original, but with some sort of prefix or postfix, that I will determine. In essence, this prefix/postfix will be the identifier for S3D to ignore the geometry and only read in the UV's of that clone.
• Export the scene (including the clones) to a single obj-file, usually including an .mtl.
• Discard the clones, or revert to the original file.

So in short, say you have a ship, with a 2 uv-channels, diffuse and AO. You end up with a scene with the original model, and a clone for the AO with the uv's copied to the first channel. Note that materials are left untouched!!!

Now, all is left is feed the obj-file into S3D. In S3D you will be given the chance to review import options and optionally choose if you want to discard one or more channels as well (so you can basically update a specific channel). Anyway, I suspect we will have an import function by the end of this month

Note: this process must be done for all submodels individually (ie. for a plane, you have the fuselage, wings, tail and whatnot). This is what makes this process so tedious for the modder/3d modeller, and why I never really liked this approach using obj. I planned with Collada, to do a full dat-file export to a single file, where all models are placed at the correct location, but this can't be done properly with obj, without screwing with the vertices (no matrix support). I'm a perfectionist, always looking for the best way. So maybe, someday, I can make a better alternative work...

[sergbuto]

Maybe it will be more convenient to have input for multiple files in S3D, each for diffuse, AO, bump, etc. Say, a menu with type-in bars and Browse buttons to input the file names under diffuse, AO, bump etc headers. Then S3D will know what UV set to get from what file and can offset UV index/numbering for the DAT file. Naturelly, input files need to be prepared accordingly.