Thanks, privateer,

i'll test it this WE. The "bird" you can d/l is still made with your older version - didn't se your post. Sorry.:oops:

I'll have a look at the "Emden".

Greetings :salute:
rowi58

privateer, why not simply write to DAT-file? Much easier (memcpy arrays), no conversion issues (binary to binary is much easier/safer and no headaches for multi uv as data structures of game and GR2 are similar), conversion is done to a single DAT-file, matrices/bones can be converted too, and you can let S3D handle imports/exports to OBJ. I think it will save you from some problems to come.

:yeah:

Hey Privateer

You're on a roll :yep:

Keep up the good work:up:

MLF

Everyone goes by own way :haha:
*********************
You speak about *.dat & S3D?
Look example...
File - Room_CR.GR2
Using Privateer's GR2_Exporter.exe - 55 objects (*.obj) have been exported/created... during 3 minutes (on my not fast machine ).
Two objects have very big size of obj-file...
...

CR_BSide.obj - file size = 407 223 KB

http://a.imageshack.us/img819/3293/crbsideobj.jpg

CR_FSide_Stairs.obj - file size = 657 264 KB

http://a.imageshack.us/img819/465/crfsidestairsobj.jpg

May be, these objects can be divided into smaller with (on) corresponding single-materials...?
...
For those who has not understood...
For comparison: SH4, file NSS_Porpoise_CR.dat, exported object Tzevi01_03_LM2.obj - file-size 2 658 KB...
Whether S3D can process such big file... 657 264 KB...? simple experiment has shown cannot...

http://a.imageshack.us/img842/9614/s3dmsg.jpg

... and pressing of "Continue" button leads to S3D hanging.

...
and Look forward - multi-materials...

I'll work on breaking the larger objs down to seperate files
after I finish a few other things.

Getting the routine finished for multi-textures will help in breaking those
larger meshes down into seperate files.

Yes, being able to break down those larger .objs would be incredible privateer. Many of the things that I would like to add more of or manipulate happen to be included in some of those huge room encompassing .obj files. It seems like that would be very difficult to include into the exporter though.

not necessarily so. He says he is able to read multi-textures...therefore he has the 'breakdown' of the 3D model. In the .dat files you have numbers to represent each piece of a 3D model. Each piece is assigned a texture and texture coordinates. So if there are multiple textures for an object then that means they are subsets of the main object. In DirectX terms it would be DrawSubset(x)

Good point, and good to hear.:yep:

Throw away the .bat file people.
:DL

Here's the basic UI version!
http://www.mediafire.com/?e48vl5q77fz8l6k

Just browse to the file you want and go!
:yeah:

Nice:up:

Thanks, Jeff. :up:
we look forward multi-materials.

P.S. tested... only... visual control of program's work is necessary (for big files).

I'm working on it and several other things now.
;)

And i thought "Good Old DOS Is Back" :haha:. OMG - i remeber those times with DR DOS 6.0 (not Microsoft), got 627 KB free RAM out of 640 KB.

It was realy good to see a BATCH file again - feeling 15 years younger :).

EOJ
(End Of Jokes): privateer - you made and you are making a wonderful job :yeah:.

Greetings
rowi58

:up: I Agree :yeah: , Well done :up: Privateer :up:

Ok since you brought this up, I took a look, and I'm sorry to say that the OBJ-files exported are highly unoptimized. For every subobject, the entire vertex, normal and texture array is exported as a whole, each time, over and over.

The first subobject (on material) is:
- 7517 vertices
- 7517 vertex normals
- 7017 texture coordinates
- 5496 faces

In privateers export however it is:
- 351977 vertices
- 351977 vertex normals
- 351977 texture coordinates
- 5496 faces

What?? Why export a massive array of which you only use 2% of data?

For the next subobject, he exports the same vertices, the same texture coordinates, the same normals, only the face-assignment obviously differ... That's roughly 30MB of extra data, for each next subobject, data you don't need because it's already written once in the file. I don't want to stomp on privateer's work, but not reusing the vertex, normal and texture arrays is bad coding. No wonder the file is so big. It should be not much more than 1/9th that size for this entire OBJ-file (and that's just an estimate, it might be even smaller).

Here's an image:

http://s3d.skwas.com/downloads/gr2obj.jpg

To import this I cut off all subobjects trailing the first. The resulting OBJ-file was 30 MB. After import I got the above. Exporting it again from S3D resulted in an OBJ-file of 856KB !! That's 97% less bytes.

Then there's the subject of S3D failing on this file reporting 350K vertices, but that makes sense since DAT-files can't hold models larger than 65K vertex indices and 65K-texture indices. Splitting the object up removes the problem as an object of 7517 vertices as per example above clearly is not a problem for S3D/DAT.

Anyway, I've looked into GR2 files myself and have written code for it in april too (to analyze), so it was an honest suggestion that it can be done and is much easier. It doesn't matter in the end, it's privateer's project, and I appreciate his work (glad he does so), and if he continues on the OBJ-path I hope he can improve it further (also based on the above analysis) or perhaps he already knows. In the end it does not matter, even if he does not improve on the above, you can break the model up in a 3D studio, or by hand in notepad like I did, and after import in S3D it will drop any unused data (Pack3D won't).

Regards, skwas

Nice post skwasjer,
:up:

Yes I am aware of the exporter doing that.
It's the old code I'm building off of that's looping garbage.
It will get corrected in a later release.
That's why I said this is only a teaser release.

I'm not a super programmer by any means.
I'm more a stumble through it and get lucky programmer.
:haha:

I didn't mean to put you down on the coding end, but as Anvart posted this info of an OBJ file of 600MB and S3D throwing an (obvious) error I scratched my head and had to take a look, because that big didnt make any sense. We'd be dealing with models of 50 to 100 million vertices.

You're doing ok sofar.:yeah:

I didn't take it that way at all Mate.
:)

I did fix the bad loop and that 600 meg file comes out at
just over 51 megs now.

If I dropped the normals it would be smaller.
Around 38+ megs.

Thanks for the situation analysis, Skwasjer. :yeah:
At last i have seen the constructive answer...
I suspected not optimised creation of obj-file too... but i wanted to see your answer. :up:
... :hmmm: or you have not understood my intentions...? with my english i cannot be assured...
...
and Granny Viewer's info about...

http://a.imageshack.us/img266/7893/c...stairsinfo.jpg