Talk:Oni Model Extractor

Hi. Just wanted to show my interest in this project of yours.

What format(s) are you planning to extract the models/anims to?

geyser 01:59, 4 December 2006 (CET)

I wonder if we could somehow avoid double-work by integrating

OpenGL viewing (and import/export) of models and anims into OUP.

I've already done basic (interactive) OpenGL in C++ (with GLUT),

and Delphi also supports GLUT, so I'm having a little look at it...

(I know you've done OpenGL in C++ too, but I'm not sure you're hot for Delphi ^^)

Interfacing OUP with modules written in Java (via JNI or something) would be optimal.

As far as model/anim extraction goes, I recommend Pierre's OniRip as a reference.

The anims are fully documented here on the wiki, levels and M3GMs soon will be.

geyser 02:11, 4 December 2006 (CET)

Hello, I just tried this on Mac OSX and got the following error:

Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:620)

at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)

at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)

at java.net.URLClassLoader.access$100(URLClassLoader.java:56)

at java.net.URLClassLoader$1.run(URLClassLoader.java:195)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(URLClassLoader.java:188)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)

at java.lang.ClassLoader.loadClass(ClassLoader.java:251)

at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

EdT

---

oh, there is a talk page - didn't notice that

EdT, i think the exception rises because of the old JVM version you are using (they say this is the case)

try downloading the latest 6th version of J2SE JRE (or JDK)

---

Apple has not released Java 6 yet. I'll just have to wait...

EdT

---

geyser, hello

that's a promising fact you say that you'll finish the ultimate-extractor in future

i don't have experience of integrating java classes into other source-code (tho i find JNI concept some kind of beautiful)

this project is not something that's going to be a flagship of extracting/viewing

it's my attempt to understand binary data reading/writing, 3d visualization, game programming (a bit)

and currently "u nas MMF, electrode, atomka, yaderka i teormech", so i'll try to suspend it until, say, March comes

---

my mind asks for some change of activity from time to time,

so i seem to be still developing from time to time, even tho

HOLIDAYS ARE COMING!!!

4

|^^^^^^^^^^^^^^^^^^^^^^|---\___      ПР�?ЗД�?ИК
|________�?ТОМК�?________||  |__\____,  К �?�?М
|______________________||__|__|_,--| ПРИХОДИТ
*+(o)+(o)-------+(o)+(o)-==-==-+(o)*

|^^^^^^^^^^^^^^^^^^^^^^|---\___      ПР�?ЗД�?ИК
|_______ЭЛЕКТРОД_______||  |__\____,  К �?�?М
|______________________||__|__|_,--| ПРИХОДИТ
*+(o)+(o)-------+(o)+(o)-==-==-+(o)*

|^^^^^^^^^^^^^^^^^^^^^^|---\___      ПР�?ЗД�?ИК
|_________ММФ__________||  |__\____,  К �?�?М
|______________________||__|__|_,--| ПРИХОДИТ
*+(o)+(o)-------+(o)+(o)-==-==-+(o)*

|^^^^^^^^^^^^^^^^^^^^^^|---\___      ПР�?ЗД�?ИК
|_______ТЕОРМЕХ________||  |__\____,  К �?�?М
|______________________||__|__|_,--| ПРИХОДИТ
*+(o)+(o)-------+(o)+(o)-==-==-+(o)*

|^^^^^^^^^^^^^^^^^^^^^^|---\___      ПР�?ЗД�?ИК
|________ЯДЕРК�?________||  |__\____,  К �?�?М
|______________________||__|__|_,--| ПРИХОДИТ
*+(o)+(o)-------+(o)+(o)-==-==-+(o)*

so, today i finished m3gm viewer, and planning in future to extract it to some 3d model format

i don't have much 3d experience

i have heard of the 3ds format, which seem to be very wide-spread,

and seem to support all the features required (textures, animations)

4

maybe you give me some advice:

what 3d-model format can be viewed/modified on both mac and pc (or linux etc) with less difficulties?

it is required to support textures and animations

4

I don't know the ideal format you're looking for. For Serious Konoko, I've only had a look at the ASCII formats for Max and Maya.

Both encode the meshes in sensible enough ways, but the storage is not the same as in game-engine-friendly formats (Oni, SE2)...

I haven't had a close enough look at how these formats (and others like FBX) encode animations and whether it's any good for Oni.

The only format I've seen so far that handles a character animation as a set of separate channels is SE2's (Lightwave-inspired).

Another feature that appealed to me in SE2's formats is that animation collections could be shared/inherited just like in Oni.

I think you could just as well export meshes (or character body sets) as OBJ for a start, and add support for animations later.

geyser 18:31, 2 December 2007 (CET)

---

i have made some research on SE2, and found this illustrative article (in russian)

also i have been searching for the 3d-model file specs, and found your post, submitted on 08-25-2006, 11:30 PM:

I mean, why can't we have standalone versions of SP4LWLayoutExportAllAnimations, SP4LWLayoutExportAllMeshes and SP4LWLayoutExportAllSkeletons (or built into Serious Editor)?

has the situation changed since that time?

i have found "SKATools.zip"

they say

This is a source code distribution of Serious Engine SKA (SKeletal Animation) model format exporter for Lightwave 7. The code is released under GNU GLPL2 (GNU General Library Public License version 2). The complete license text is available in file COPYING. To compile the plugin, you will need Lightwave SDK package, obtainable from www.lightwave3d.com. The project was built using Microsoft VisualC++ 6.0 w/sp5 and tested for Lightwave 7.0. Other compilers and some older versions of LW (namely 6.5) might or might not work - we didn't design or test for that. The code is free (see COPYING for exact definition of "free software"), so there are no warranties. We supply the plugin and the source for your convenience. You may use it as you like as long as you obey the license. Feel free to use it as example for creating SKA export plugins for other modeling packages and/or converters. Note that if you make modifications to the plugin you need to have the new sources. The source is not really best example of clean code, but it does the work. If you have any questions, please visit the Seriously! forums. (See www.seriouscommunity.com, www.planetserious.com or www.3dactionplanet.com/serioussam .) Alen Ladavac Croteam

seems that these are the sources for the exporter LWO -> SE2

is this the thing you asked for in that post above?

• nicely done ASCII you made there

kuchumovn

---

It won's let me view the 3d parts :(

71.231.63.236 19

43, 16 December 2007 (CET)

hello

do you mean oncc bodyparts? currently no - only a short list of in-game movable 3d objects (like fan, truck, plane, doors, powerups): big ones are also split into smaller parts

Kuchumovn 23

27, 16 December 2007 (CET)

---

Please specify what formats you export meshes/animations to...

That's one crucial piece of info missing from the project page.

geyser 21:56, 6 January 2008 (CET)

maybe, if some time animations exporting gets implemented

currently i have found out that 3DStudio displays nothing of the input 3ds file (and Deep Exploration too)

actually 3ds is like a sandbox for extracting, because it doesn't store normals data, and it is extracted in multiple files, and different limitations and so on

the preferred format is LWO+ (i asked mirex, he approved)

Kuchumovn 11:46, 7 January 2008 (CET)

Mirex is probably a good advisor in terms of portability.

But I'm afraid that any proprietary format means trouble.

FBX and Collada have nice SDKs, and OBJ etc are ASCII.

For meshes and characters, I think OBJ is good enough.

Exporting level parts is a completely different story.

It would be better to export AGDB modules separately.

geyser 19:01, 7 January 2008 (CET)

i haven't heard about collada before

seems that this 3d-format is the one i would prefer rather than any other one (since i am java minded, and java encapsulates XML)

but it is a relatively complex format, jugdging from the page count int the specification PDF

maybe one time i'll read it, and these 2 tutorials

actually it is already a trivial step for me to implement 3ds animations extration, since today i found some sources hidden in the sea of internet

but as for LWO+ - it is eliminated in my mind from now

as for levels - i don't think i'll write an exporter for them since they are poorly designed (for me)

i think it is much more rational to make new levels with high resolution textures and higher amount of details, and with some physics (как написали про какую-то игру: "поставили бочки - это, да, разнообразит игровой процесс, но для чего же их наполнили цементом?!")

actually my line of thinking was like it is much more difficult to create character models and animate them, than to create new levels

even more - models and animations, created by amateurs, would be horrible

but coding, texturing and level modelling is what oni fans can handle on an appropriate level

наш лектор (половина потока идёт на комиссию)

Kuchumovn 21:10, 7 January 2008 (CET)

tonight i've been particularly thinking on what is OME supposed to do

in fact i haven't noticed that 3d-editors i've used before have only one animation track

that means if OME is supposed to extract all the animations, then 3d-editors' formats are not applicable

seems that collada can store multiple animations

so 3ds becomes more sandboxier

still i think i'll implement single animation extraction just to "finish the event chain" (like they say it in esoterics - unfinished business may take your powers; actually tonight i woke up, and there was a mess in my head about extracting animations to 3ds - it was like if i was insane; actually it happens sometimes - i create different insane theories, create new dimensions, new numbers, new figures, as if i took lsd before going to bed)

Kuchumovn 10:10, 8 January 2008 (CET)

---

"then you can import it to a 3d-editor and maybe flip normals for some bodyparts" It's up to you, ku4um, to detect the polygons that need to be flipped, and export them properly ;)

geyser

i guess that face reverting can be done like this:

maybe i'll try it today

Kuchumovn

The issue is only with Oni's meshes and the way they're rendered in Oni. Basically, they're mostly using the face normals for backface culling, rather than the vertex order.

That is what happens for character meshes and animated cutscene objects. Certain body parts are obtained by flipping existing ones, which preserves correct face normals, but flips the polygons. Same for "cloned-and-mirrored" parts of a single mesh (e.g., wheels of a car). Therefore, if you export ONCC or OBAN meshes and preserve the triangles listed in the IDXA as strips, some of them will be culled incorrectly by 3D programs. Because 3D tools typically use the vertex order for backface culling. And because Oni does not use the vertex order at all for character and "object" M3GM - it uses face normals instead. The reason why these meshes have inconsistent vertex ordering is because that order is irrelevant to Oni. The only way to fix the order is to check face normals against triangle orientation. For character M3GM, the mesh is usually flipped as a whole, but for car wheels, you have to check every triangle, because the flipping may be limited to a part of the mesh (e.g., left wheel is not flipped, and right wheel is a flipped clone).

For powerups (and probably weapons, turrets, consoles, particles etc as well), they'not culling the backfaces, at least not according to the face normals. We know that because some face normals are just plain wrong for, e.g., powerup_shield, for example, has some messy normals, inconsistent with the layout of the polygons for some reason. There are normals pointing inwards for that one, so there is no way it can be culled based on those. Either it's not culled at all, or it's culled based on the usual vertex order (which, for powerups and weapons, is consistent). This basically means that you can export all these "minor" meshes without flipping the triangles at all. Since the normals can be wrong, just ignore them for these meshes (powerups, weapons, turrets, consoles, particles etc) and do not check them again triangle orientations.

Other than that, your algorithm for checking normals and flipping polygons is correct. If for the "interpolated" normal you use not the (possibly wrong) normals from VCRA but your own interpolation (and preferably evaluate the vertex normals as well), then you can apply that algorithm to every face of every mesh in Oni. You can, however, spare yourself that trouble and use the above rules. For character meshes, you only have to do the checking for one face, then flip the triangles for the whole mesh if necessary. For powerups etc, never flip the triangles. For cutscene objects, do an extensive check and flip every face individually, as needed.

The problem is just that, e.g., powerup_shield (and powerup_cell IIRC) has wrong normals (even pointing inwards), so I wouldn't recommend to handle these in the same systematic way as cutscene objects. As for the lack of a flag, you're correct, but the cutscene objects belong to the OBOA hierarchy, so you can detect them that way.

geyser

i.e. one can check all the OBOAs in the level, and if some M3GM is not part of those OBOA M3GAs, then it is not a cutscene object?

Kuchumovn

For example, yeah. Rather than backtracking the hierarchy, you can also list the cutscene M3GM directly through the ONLV tree.

I think the easiest way to handle this is to NOT bother detecting whether a mesh "is not a cutscene object". Here's my suggestion.

Unnamed meshes should only be listed and exported through their respective parents (ONCC/TRBS, ONWC, TURR, CONS, etc).

Named ones can be listed without any distinction, and viewed/exported in a silly way (no normals checking or triangle flipping).

However, you should also allow the user to list OFGA and M3GA meshes through their respective parents (i.e., additional trees).

When the user lists furniture/cutscene M3GM through that tree, THEN the normals will be checked before viewing or exporting.

So you have a lazy default behaviour for standalone named meshes, and an optional, more zealous checking for "array meshes".

geyser

i've just implemented normal flipping for ONCC - it appeared to be a 15-minute job (shorter than pating this discussion here)

i think then i'll make normal flipping also for powerup_shield today

Kuchumovn 18:25, 15 January 2008 (CET)

normal flipping has been implemented

normal of a face is then defined as [AC, AB]

normals of bodyparts are not recalculated, normals of standalone M3GM are recalculated by averaging parent face normals

Kuchumovn 20:18, 15 January 2008 (CET)

these days i have been fixing my university business (сдал зачёты и психологию - фрейд извращенец), and tried to add some functionality to OME

in this thread (https://collada.org/public_forum/viewtopic.php?p=3457, dead link) i have been requesting for support on COLLADA file format

today i've finished extracting from M3GM to COLLADA (and i might say that COLLADA is very natural, essential, or whatever)

you can get a C++ COLLADA loader here (a bunch of sample models is included, even with animations)

Kuchumovn 00:19, 28 January 2008 (CET)

extracting from ONCC to COLLADA has been implemented

currently there is no skeletal hierarchy - every bone is being translated independently

Kuchumovn 20:01, 28 January 2008 (CET)

skeletal data has been implemented

also, while testing the exporter, i've found that only this COLLADA loader gives satisfactory results

i've googled a bit, and haven't found any other COLLADA loader (even 3DS MAX doesn't load the exported DAE files; btw, they have written there "Autodesk (.FBX, .DAE)" - i think someone may trail them for this)

maybe you've met some other satisfactory COLLADA loaders?

Kuchumovn 14:15, 30 January 2008 (CET)

• Other loaders: you can try Blender. Seems to work correctly if you don't have animations in the .dae file.
• 3DS Max (and Maya): As far as I know you need the ColladaMax (ColladaMaya) plugin from Feeling Software. In addition Autodesk's FBX Converter can convert from/to Collada and FBX/3DS/OBJ. As for "trailing" them... yeah suuuure...
• Me: I'm using XSI Mod Tool. Unlike Blender it can import animations correctly.

Neo

thanks, i'll try these out

Kuchumovn 16:48, 30 January 2008 (CET)

---

Site http://myjavaserver.com/~kuchumovn/ome/ is unavailable. :\ -- Striker

Thanks for letting us know. It seems that the whole site is down. Check the article on OME again for a new download link. --Iritscen 23:59, 18 February 2009 (CET)