User talk:Neo: Difference between revisions

From OniGalore
Jump to navigation Jump to search
No edit summary
m (marked dead link)
 
(185 intermediate revisions by 11 users not shown)
Line 1: Line 1:
Heh, EdT wants explosive barrels, right? Well, me too.
'''Talk page archives''': [[User_talk:Neo/Archive1|#1]] - [[User_talk:Neo/Archive2|#2]] - [[User_talk:Neo/Archive3|#3]] - [[User_talk:Neo/Archive4|#4]] - [[User_talk:Neo/Archive5|#5]]


Nah, here comes my request. Is there possibility to increase total amount of spawned PAR3 ? Currently it is 1000. I think like 100 000 would be nice. Or is it short, limited to about 65 000 ??? That would be nice as well.
Hi Neo, In the latest oni split 0.9.55, there seems to be a problem with converting ONCC files,
:REASON: 1000 particles maximum. Each decal is count as particle. We want to make AE shinier. That involves more particles spawned at one time, especially during gang fights. Even in original Oni, when playing arena scripts, sometimes you can see that victim is hit but no flash appears as all decals are used at that moment. So we should increase number of decals for those flashes. But then, when limit (1000) is hit, engine starts removing the oldest particles again.
It fails to convert ONCC.xml files made by earlier to oni files .. says something about jump fields, the ONCC xml created by older versions are different from the ones created by this one, different fields <Jump Constants> and <Air Constants> instead of <Physics>, that would be ok we could switch to the new layout. However onisplit v.55 also fails to convert ONCC.xml it created back to oni. .. convert any ONCC.oni to xml, try to convert that xml back to oni, it fails.


:100 000 is maybe overrated, but I think it this way: 200 decals for each fight PAR3, 5 000 for each various bulletholes/burns/shrapnels/casing/shielding/etc.
2- It is also unable to convert a TRAM.oni file made from a dae by older versions back to xml : Operation is not valid due to current state of object. (containing QKEYS) while 0.941 is able to convert them.


Thank you in advance.
reported by Samer on July 10 2011
:P.S.: XML TRAMs? You rock! ^_^
:--[[User:Loser|Loser]] 07:23, 10 September 2008 (CEST)


For decals you can try changing this value in the exe:


  0x4EAD6: ff 8f 01 00 - int32, decal buffer size in bytes


For particles you can try changing these:
Hi Neo, a bug has been ecountered by me in OniSplit's xml export. The bug applies on versions 0.9.50.0 and 0.9.52.0. If exported TRAM file has direct animation links, only the second direct link is written into XML file. The first direct link is ignored (is always an empty element).


  0x55D63: 50 C3 00 00 - int32, particle memory block size
This is an excerpt from KONCOMcomb_p_p XML file as created by OniSplit 0.9.52.0:
  0x55D9F: 50 C3 00 00
        <DirectAnimations>
  0x55DAD: 50 C3 00 00
            <Link />
  0x582CF: 50 C3 00 00
            <Link>TRAMKONCOMcomb_p_p_k</Link>
        </DirectAnimations>


It should be:
        <DirectAnimations>
            <Link>TRAMKONCOMcomb_p_p_p</Link>
            <Link>TRAMKONCOMcomb_p_p_k</Link>
        </DirectAnimations>


The decals hack might work (try double that value) but I'm not sure about particles. It would be simpler to increase the number of 50000 bytes memory blocks (the default is 100) but that cannot be done so we need to increase the block size which can lead to unexpected problems.
Binary (*.oni) files contain both direct links. Exported XML files don't. Since usually only the first direct link is used, this bug poses quite a nuisance. Thank you in advance.


And there's no way you can get 100000 particles unless you have a 100GHz processor :)
: It might be that the binary (oni/exe) are corrupted. My version of TRAMKONCOMcomb_p_p.oni was correctly extracted with onisplit 52. --[[User:Paradox-01|paradox-01]] 19:00, 8 July 2011 (CEST)


[[User:Neo|Neo]]
While I'm here I will take the chance to also ask something. I'm trying to create a combo. The animations work fine with animation type Kick, Kick2, Kick3 but not with KickRight, KrKr*, KrKrKr**. Could it be that those* animation types are dead? I hope you will find out what's wrong. --[[User:Paradox-01|paradox-01]] 19:00, 8 July 2011 (CEST)


==OniSplit 0.9.27==
: Loser: The problem more than likely was the fact that the TRAMKONCOMcomb_p_p_p.oni was not in the same directory as  TRAMKONCOMcomb_p_p. To test, I removed TRAMKONCOMcomb_p_p_p.oni and got the same result as you did, added it back and got the correct output. OniSplit wants all the files to be in the same directory.  [[User:EdT|EdT]] 23:36, 8 July 2011 (CEST)
[http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniSplit/OniSplit|_v0.9.27.zip OniSplit v0.9.27]


Bugfixes and xml export/import for [[OBD:BINA/TMBD|TMBD]].


[[User:Neo|Neo]]


Hey, testing out TRAM import right now...using it for an explosive barrel.
----
 
I have a 1 frame animation where the pelvis consists of this - <EKey>1 0 0 0</EKey> I know the first part is the number of frames, but what are the others? I need to rotate the barrel 90 degrees upward.


See this: http://i35.photobucket.com/albums/d159/gumbyWA/barrel.jpg


[[User:Gumby|Gumby]] 19:25, 11 September 2008 (CEST)
Neo, do you think we can have something like a -nodeps argument added to OniSplit? We could use a way to prevent the program from automatically following all dependencies when exporting files like ONCCs to XML. --[[User:Iritscen|Iritscen]] 14:26, 6 July 2011 (CEST)
:Oops, never mind, it sounds like this is already OniSplit's default behavior.... --[[User:Iritscen|Iritscen]] 16:24, 6 July 2011 (CEST)


You can take a look here: [[OBD:TRAM/raw0x34]]. Appart from the fact that I swapped the number of frames with the rotations it's the same thing. To summarize:
-----
Pathfinding issue fixed, though it seems to be still slightly off:


The 3 values after number of frames are:
[[Image:junkyard_PFG.jpg]]
:*rotations around X, Y and Z axes
:*stored as signed integers with values between -32768 and 32767


To convert those values to degrees you need to multiply by (180 / 32767.5).
There is still the issue of falling through the ground.


To convert from degrees you need to multiply by (32767.5 / 180).
level files are here: http://edt.oni2.net/testlevel/junkyard.zip


You probably need to rotate the barrel by 90 degrees around X or Z axis. That probably means <EKey>1 16384 0 0</EKey> or <EKey>1 0 0 16384</EKey>
[[User:EdT|EdT]] 03:14, 18 June 2011 (CEST)
 
[[User:Neo|Neo]]


Hah! It worked. Thank you very much. I was wondering why they were so large, for being rotations. ^_^


[[User:Gumby|Gumby]] 22:06, 11 September 2008 (CEST)


A mystery: If you set a character to be invulnerable through the TRAM, the refuses to shoot you with the Black Adder. Do you know why?
Hi Neo,


[[User:Gumby|Gumby]] 01:16, 12 September 2008 (CEST)
I was able to create the pathfinding grids, however, they are offset from the geometry. Also, there is a spot where you will fall through the ground.


Nope. Are you sure it is because of the invulnerability?
[[Image:junkyard.png]]


[[User:Neo|Neo]]
The bnv itself is correct:


Thanks you for TRAM done. You are '''No.1'''
[[Image:junkyard_bnv.png]]


Anyways, here is report on increasing particle memory blocks' size: Failure. Max value that was Oni able to withstand was FF|FF|00|00. Then there was maybe + 10 or so particles, but in exchange it was extremely unstable. More than 65535 resulted in crash when some particle was spawned. Dang it. This is 100% wrong way.
Here are my files: http://edt.oni2.net/testlevel/TestLevel.zip


Decal buffer incrementation: Failure as well. Tried 2x original value, then 1.5x. Oni hangs in both cases when there is too much decals. And last decal was weridly deformed.
EDIT: Tested OniSplit with the arena level data: <nowiki>http://mods.oni2.net/system/files/80200ArenaofHurt.zip</nowiki>
Extracted the AKEV, then used create:akev to import the level. The pathfinding grids were offset from the geometry and there were areas where the player will fall through the floor.  


No use. We need new engine or source... but thank you for informations.
[[User:EdT|EdT]] 01:03, 17 June 2011 (CEST)


P.S.: How can I find if I caused memory corruption ? I am modyfing throws now, and Geyser told me that in previous version of TRAM modifications, some TRAMs caused mem corruption. I don't want to repeat same mistakes. Thank you in advance.
-----


--[[User:Loser|Loser]] 16:12, 12 September 2008 (CEST)


OK, I did some more checks:
:*Particles: there's basically no way to have a particle block larger than 65535. However, to my knowledge the maximum size of a particle is 256 bytes so with this increase you should be able to get 600 more particles (60 / per block * 100 blocks).
:*Decals: in theory it is possible to increase the decal buffer size but the hack would be rather extensive. Basically you would need something like Daodan dll to replace some function in the exe.


Hi Neo,
I have tried Your ".dae" to ".xml" animation importer. I keep getting message ".dae files cannot be imported as TRAM". Can you tell me please where is the problem? Thank you. --[[User:Loser|Loser]] 13:00, 11 July 2010 (UTC)


TRAM and memory corruption: tipically you cannot find it until the game crashes. If you manage to make it crash consistently with new animations then give me the animations and I'll see what I can do.
Hello, to import an animation you need an xml file and a dae file. If you try to export a TRAM to xml you get both files and when importing you need to provide the xml file, not the dae file. The dae file is referenced from inside the xml file (see the DaeImport element) [[User:Neo|Neo]]


[[User:Neo|Neo]]


On the invulnerable TRAM: Yes, I am sure. The character has the invulnerable animation as a default. I commmand him to do another animation, he gets shot at. When the animation stops, and his invunerable idle animation starts, the shooting stops again.
New OniSplit version: OniSplit v0.9.52 (<nowiki>https://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniSplit/OniSplit%5E_v0.9.52.zip</nowiki>, dead link)


On something else:
What's new:
:* When a TRBS file is exported to xml the geometry is exported to separate .dae files, one .dae file for each LOD
:* New -anim-body option. This allows a particular body (ONCC or TRBS) to be specified when exporting animations:


I thought dangerous particle awareness was fixed, but avoiding them was broken? In this image: http://img134.imageshack.us/img134/5205/linesun5.jpg It seems that awareness is still broken, look at the blue (or used to be blue, until my image editing program messed up the colors) lines. They still point toward the origin. Aren't they supposed to point toward the danger? However, he does avoid it properly as long as you aren't standing between him and the origin.
  onisplit -extract:xml out -anim-body:ONCCbarabus.oni TRAMsomething.oni


[[User:Gumby|Gumby]] 22:14, 12 September 2008 (CEST)
:* New -recurse option for the xml exporter. Have fun :)


Invulnerable TRAM: so, if my understanding is correct an AI character won't shoot at another character that runs an invulnerable animation and that happens only with Black Adder? Kind of strange if it happens only with one particular weapon.
  onisplit -extract:xml out -recurse ONCCbarabus.oni


Projectile awareness: there's another bug in that function, here's the fix
:* Changed light color in the environment importer to white (it used to be blueish)
:* New -env-notxmp option. This prevents the automatic creation of TXMP files while importing the environment.
:* Made -normals work when importing TRBS from xml + dae files.


:*file offset 0x9C110, new value 0x6C
New OniSplit version: OniSplit v0.9.41


[[User:Neo|Neo]]
What's new:


Thanks. I've only tested the TRAM against the Black adder, SBG, and Plasma Rifle. Let me go try the VDG and the Campbell.
:* fixed the Collada importer to work with 3DSMax exported files


[[User:Gumby|Gumby]] 23:04, 12 September 2008 (CEST)
New OniSplit version: OniSplit v0.9.40


http://gumby701.googlepages.com/bomber.wmv
What's new:


[[User:Gumby|Gumby]] 23:58, 12 September 2008 (CEST)
:* support for exporting/importing [[OBD:BINA/SABD|sound animations]] to/from xml files
:* better Collada export for environment
:* support for full color transparent textures (-format:bgra32 on the command line, ARGB8888 format in an xml file)
:* different (hopefully better) xml export format for animations (this one is actually from 0.9.38 but since that wasn't mentioned here...)
:* a more or less complete animation importer. This one deservers some notes:
::-unlike other importers that produce .oni files this one produces and .xml file (similar to the one you get when exporting a TRAM)
::when you do
  onisplit -create:tram target_dir animation.dae
::in the target dir you'll get a TRAManimation.xml file.
::You need to add some stuff to that file to make it actually work as an animation. In particular the animation type, from/to states and varient needs to be set.
::-For all I know this works with animations exported from Oni and modified in Softimage. If you come up with a completly new animation it should work as long as the skeleton is similar to the one used in Oni.
::-Note that the geometry that is present inside the Collada file is used to compute the "vertical extents" so it better be the same or close to the one the animation is intended for.
::-The biggest problem are the attacks. While it's not difficult to add attacks to the xml file, computing the necessary "extents" is not going to be easy. I guess in the end I'll have to add some command to OniSplit to do it.
::-Everything else that I forgot :)


Earlier today I realized that, at least with my copy of the modded Oni executable, AI does not avoid persistent dangers like the Screaming Cell or Scram warheads, only gunfire that I emit constantly from my weapon. Is that supposed to be fixed, or will the above hex change fix it, or was it never fixed at all? I know I saw a hack for avoiding the Cell being demoed on YouTube quite some time ago.
[[User:Neo|Neo]]


@ Gumby's vid: o.O The lines don't seem to have any bearing on the Thug's ability to dodge the threat; also, why didn't the MB disappear post-explosion? --[[User:Iritscen|Iritscen]] 03:32, 13 September 2008 (CEST)
New OniSplit version: OniSplit v0.9.37


Yes, use that hex value. The lines do something. :D They don't appear if there isn't a threat. They are supposed to point towards the bomber, but they don't. Don't know why, but I'm looking into it, unless Neo knows. When you use stuff like the Screaming Cannon, the lines point toward the warhead (IIRC).
What's new:


[[User:Gumby|Gumby]] 06:00, 13 September 2008 (CEST)
:* support for transparency in the environment importer


So I can't see mem corruption until it crashes? Good X_X. Heh, here comes my two cents for AI2 dodging:


1st, Gumby, that blue-lines-constantly-point-to-origin bug was reported by me several months ago. I reported it repeatedly, even with video proof, but got nothing ("you have to wait, we have more important things to do..."). So thank you that you finally got answer for me ^_^. You are like magician. You ask -> you get.
New OniSplit version: OniSplit v0.9.35


2nd, those blue lines are pointing towards "source of danger" (Neo has better name for it?). In case of firingspread, source is character's weapon. In case of projectiles, source is dangerous projectile. That green line is something like "vector of movement", pointing where character moves right now. Dodging can be (at least for firingspread) modified in [[ONCC]]. You can set how strong is this "vector" of dodging (so when AI2 has vector towards you AND you shoot, it can dodge more or less). You can also set how long this vector should last from the moment it was created.  Don't know if those values affect projectile dodging as well.
What's new:


Iritscen: Instructions how to get projectile awerness (credits go to Neo): In standard EXE, find and change:
:* conversion of recorded films (.dat binary files) to xml files that can be used to create FILM .oni files
:0x9C07C: change 30 to 6C
:0x9C080: change 34 to 70
:0x9C084: change 38 to 74
:0x9C110: change 30 to 6C
That should do it.


Hey Neo, can we delete collision stuff at the top of the page? I saved it, so it is not neccessary to leave it here. And that paragraph is huge. Or better: Can I move it to some other page?
    OniSplit film2xml out_dir film.dat


--[[User:Loser|Loser]] 07:57, 13 September 2008 (CEST)
----
Neo


Thank geyser. I asked him on it, and then he must have asked Neo. But the bomber awareness is still messed up. No matter what, he dodges in the direction of the origin. Look at the video again. The blue lines aren't pointed towards the bomber, AND he runs toward the bomber (and the origin, i think), instead of away. And thank you Loser for making the wonderful ONCCs that come with Edition. They really help with dodging. You will have to help me soon though. I'm working on making the bombers more "suicidal". :)
I get this error message using the command create:tram


[[User:Gumby|Gumby]] 08:16, 13 September 2008 (CEST)
  System.NotSupportedException: Invalid rotation axis {X:0 Y:0 Z:-1} for rotate transform in animation pelvis-node-ry
 
  at Oni.Totoro.AnimationDaeReader.FindRotations () [0x00000]
Hey Neo, how do I add a Character collision event + attachement in a PAR3 xml file?
  at Oni.Totoro.AnimationDaeReader.Import (System.String filePath, System.String outputDirPath) [0x00000]  
 
  at Oni.Program.CreateGeneric (System.String[] args) [0x00000]
[[User:Gumby|Gumby]] 08:40, 13 September 2008 (CEST)
  at Oni.Program.Main (System.String[] args) [0x00000]  (1)
 
Some quick answer to the projectile awareness stuff:
:* there was a bug which prevent it from computing correctly the distance between character and projectile; this one prevent dodging completly
:* there was another bug (the new 0x9C110 fix) that cause it to see a wrong direction vector; this one caused "alwatys dodge towards origin" behvaior
:* I don't know what's up with the bomber. I'm quite surprised that it does any kind of dodging because the bomber is not a projectile. I assume it tries to dodge the death particle but that particle has no velocity and that may cause the behavior you are seeing.


[[User:Neo|Neo]]
The dae files are here: <nowiki>http://www.filefront.com/14507129/dae.rar</nowiki> (dead link)


Hmm. A zero value for velocity might screw up things? I'll try to make a bomber particle that moves up and down or something.  
xml animation file here: <nowiki>http://www.filefront.com/14507115/ID%20walking.xaf</nowiki> (dead link)


[[User:Gumby|Gumby]] 08:57, 13 September 2008 (CEST)
Thanks [[User:EdT|EdT]]


Particle stuff:
Yep, caused by Z-up. I'll see what I can do.
:* for character collision event (HitCharacter) see one of the particles used with weapon, for example BINA3RAPw1_tap_p01.
:* for attachment add <HasAttachmentMatrix>true</HasAttachmentMatrix> in Properties section


[[User:Neo|Neo]]
[[User:Neo|Neo]]


More things I missed\messed up in my reply:
Hi Neo,
*The thug dodges toward an axis.
*The bomber was shapeshifted Konoko, making the body not disappear
*The old screamer video was unmodded Oni
*Remember that the hex changes are PC only


[[User:Gumby|Gumby]] 09:34, 13 September 2008 (CEST)
When you have time, can you take a look at this:


:Loser, I oughta slap you around with a large trout for this - '''I reported it repeatedly, even with video proof, but got nothing ("you have to wait, we have more important things to do...").''' - you could at least have linked to [http://oni.bungie.org/community/forum/viewtopic.php?pid=4897#p4897 your report], so that people can see what I ''really'' told you then.
[[Image:TRBSproblem.jpg]]
:And as for this - '''Hey Neo, can we delete collision stuff at the top of the page? I saved it, so it is not neccessary to leave it here.''' - I oughta slap you with an even larger trout for being so selfish about documentation. Where have you backed up that knowledge? on your own HDD? why, thank you...
:And you know what else? maybe then I should club you to death with the mother of all trouts, for deleting important documentation like the [http://loser.oni2.net/Videos/Projectile_dodge_issue.wmv dodge-related "video proof"] from your oni2.net account. It's irresponsible to go deleting stuff like that.
::[[User:Geyser|geyser]] 11:05, 13 September 2008 (CEST)
:Iritscen, when you say this - '''I know I saw a hack for avoiding the Cell being demoed on YouTube quite some time ago.''' - your "knowledge" is wrong. Look at the video again, then at its end titles, then at the video details and comments: http://www.youtube.com/watch?v=C8zpfiHeR_s
:Because of the nature of the bug, dodging mostly worked as long as the dodging took place close to the level's origin, so for the needs of the trailer, for example, it was already quite possible to set up an actual sequence, with anything from screamer to grenade to bomber.
:Loser up there gave you instructions for the standard PC engine: [[AE:EXE]]. There is no corresponding hack for the PC demo of for OMNI's engine yet. Keep an eye on this page, which will be updated with the info soon enough: [[AE:OMNI]]
::[[User:Geyser|geyser]] 11:05, 13 September 2008 (CEST)


When I use the latest FBX Converter 2010.2 to convert FBX to DAE, I get this problem.  However, when I use an older version, it works fine.  Here are the DAEs from both version: http://edt.oni2.net/temp/TRBSproblem.zip G2 is uses the new version, G1 uses the old.


Wow, I got PWNED. Hard. And I accept it ^_^.
Thanks [[User:EdT|EdT]]
:'''I reported it repeatedly, even with video proof, but got nothing ("you have to wait, we have more important things to do...")'''
:: '''*slap, right cheek hurts*''' - My apologies, I was mistaken. Sorry about it.
:'''Hey Neo, can we delete collision stuff at the top of the page? I saved it, so it is not neccessary to leave it here'''
:: '''*Fish strike parried*'''- эй, экономи рыбу, друг ( hey, save teh fish, friend) and read next but one line instead: '''Or better: Can I move it to some other page?'''
:'''maybe then I should club you to death...'''
:: '''*slap, left cheek hurts*''' Do it ^_^. It was accident, really. I was cleaning some other files in video folder (those which were really old) but this was poor casualty together with other one video (about weird character-stair collisions)


So what. Now I am going to post that collision stuff on some page (and you will most likely rearrange it then ^_-). I am glad that AI2s finally fully react on projectiles, many thanks to Neo and you. And as for my old videos... let them R.I.P (and put me next to them if you want ^_^ ).
Oh boy, the new converter uses matrix transforms instead of individual scale/rotate/translate transforms. I'll see what I can do...
:--[[User:Loser|Loser]] 12:23, 13 September 2008 (CEST)


Hey, Neo, just remembered something. Your ONWC export needs a slight change.
[[User:Neo|Neo]]


0x048 - 'roughjustice' delay between shots in frames


[[User:Gumby|Gumby]] 23:25, 13 September 2008 (CEST)
----


Partially fixed the awareness. I need to figure out why the spheres don't move like they are supposed to be doing. I have a feeling once I get them to move around, the  characters will "pay attention" to them better.
The Iron Demon walks! Sorta...


http://drop.io/download/48cc75dc/b7052019762bf4f5aa859de9bb6689d9bb5f32c1/b2b104c0-6431-012b-6d03-0012799407ec/167e5950-6432-012b-19f4-f1daf8099b16/aware.wmv
You can see the video here: http://edt.oni2.net/ID/IDwalk.wmv


[[User:Gumby|Gumby]] 07:41, 14 September 2008 (CEST)
I converted the files from Bobbysoon (TRAMID_run1stepb.DAE, TRAMID_runstart.DAE, TRAMID_runstop.DAE) to xml.  The XML gave the pelvis height as <Height>-2175.5</Height>, so I removed the negative and divided the height by 100.  But as you can see, the model floats above the ground.  Also, the velocity has some large numbers in the first part <Velocity>-4.076141 0</Velocity> I think that is the cause of the ID moving sideways not forward.


Aha. It worked. I just need to make it attract (to me) properly. Why don't Particle flags show up in "-help enums"?
Files here: http://edt.oni2.net/ID/ID_Files.zip


[[User:Gumby|Gumby]] 07:59, 14 September 2008 (CEST)
[[User:EdT|EdT]]


Two bugs.  
:Ha ha, that's going in my album of weird modding results. Anyway, I didn't even realize that animations were supposed to work yet, I thought we were waiting for an update to OniSplit. --[[User:Iritscen|Iritscen]] 14:33, 29 November 2009 (UTC)


1. Characters can get stuck in the corner if you use soemthing like the screamer. (They try to run away, but get cornered, and don't want to dodge through the particle. Pretty predictable, normal behavoir. No big deal).


2. If character cannot see the character that created a dangerous particle, they don't dodge it at all.
----


[[User:Gumby|Gumby]] 08:58, 14 September 2008 (CEST)
Hi Neo,


==OniSplit 0.9.28==
Having problems converting DAEs to trams. I put all the files in a zip and included a ReadMe with the description of the errors. <nowiki>http://edt.oni2.net/temp/NeoTRAM.zip</nowiki>
[http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniSplit/OniSplit|_v0.9.28.zip OniSplit v0.9.28]


:* added xml support for [[OBD:BINA/ONIE|ONIE]].
I was trying to make new animations, whenever you have time, please take a look.  Thanks [[User:EdT|EdT]]
:* -help enums now lists particle related values


[[User:Neo|Neo]]


Aha, thanks very much.
----
Hmm... I just discovered that I can't export TXMPs from a .dat file to the PNG format. I am attempting to use the -extract:png command on a virgin .dat file. The -extract:tga options works fine, but the -extract:png option gives:
System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus --->  System.DllNotFoundException: gdiplus.dll
  at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)
  at System.Drawing.GDIPlus..cctor () [0x00000]
  --- End of inner exception stack trace ---
  at System.Drawing.Bitmap..ctor (Int32 width, Int32 height, PixelFormat format) [0x00000]
  at (wrapper remoting-invoke-with-check) System.Drawing.Bitmap:.ctor (int,int,System.Drawing.Imaging.PixelFormat)
  at Oni.Imaging.SysExporter.ExportInstance (Oni.InstanceDescriptor descriptor) [0x00000]
  at Oni.Exporter.ExportInstanceList (System.Collections.Generic.List`1 descriptors) [0x00000]
  at Oni.Exporter.Export (Oni.InstanceFileManager fileManager, System.String sourceFilePath, System.String filter) [0x00000]
  at Oni.Program.ExtractTextures (System.String[] args) [0x00000]
  at Oni.Program.Main (System.String[] args) [0x00000]
This occurred in both 0.9.38 and 0.9.41 on my Mac. I used to always extract TXMPs as TGA, so I don't know when this actually worked for me. --[[User:Iritscen|Iritscen]] 17:54, 2 January 2010 (UTC)


[[User:Gumby|Gumby]] 21:39, 14 September 2008 (CEST)
:TGA always works because it's all done in OniSplit. For PNG/JPG I'm using the framework (.NET/Mono) and Mono seems to have a problem. [[User:Neo|Neo]]


Note about ONIE import: keep in mind that if you want to add new impact/materials you'll have to manually create the coresponding Mtrl*.oni and Impt*.oni files.  
:I just tested it myself and I was able to extract all the textures from a virgin .dat file as PNG.  I'm using the latest version 0.9.45 and the latest Mono framework.  OSX 10.5.8 and 10.6.2 [[User:EdT|EdT]]


[[User:Neo|Neo]]
::Okay, after many aborted attempts at updating mono (I was running 2.0.1) by building from source or using their binary installer, I realized that the installer was putting the files in some meaningless directory, and I ended up copying them to the right system directories, hoping I didn't overwrite libraries that were supposed to stay unchanged. Who knows what the consequences will be down the road for other stuff, but OniSplit now exports PNGs properly for me! --[[User:Iritscen|Iritscen]] 20:28, 3 January 2010 (UTC)


Neo, Can you please add to your to-do list the ability to import SNDD files, this is a request from OCF.  Thanks [[User:EdT|EdT]] 19:27, 20 September 2008 (CEST)
----
 
Observations of importing TRAMs to XSI.
 
[http://www.paradox.oni2.net/IGSt_bug.zip Minor IGSt bug found.] The import doesn't recognize new lines which comes from "<text> </text>". There're 00 instead of 20 (one per such instance) in the reconverted file.
 
[[User:Paradox-01|Paradox-01]] 16:35, 26 September 2008 (CEST)
 
Hey, just posting on the issue of the animation freezing bug (the camera flying away when you enter a cheat). It seems that the flag in memory is only turned on when you exit the menu, not when you enter the cheat. Ahh, not sure if that helps. It has been happening to me a lot lately (every time I open the game), but it could be anything from using Rossy's C dll (testing if that aggravates it), to...well I don't know. If you could take a look at it that would be great though.[[User:Gumby|Gumby]] 06:27, 28 September 2008 (CEST)
 
 
Neo,
 
I got this error message when importing a TRBS:


  System.IndexOutOfRangeException: Array index is out of range.
Sometimes, imported TRAMs will have odd rotations mainly related to the pelvis and thighs. Here is one example, the Striker's walking TRAM:
  at Oni.Vector2.FromArray (System.Single[] values, Int32 index) [0x00000]
http://edt.oni2.net/TRAMS/WalkOS.wmv  As you can see the pelvis and thighs are rotating in an odd fashion. This is due to euler vs quaternion rotations. To see it correctly in XSI, you can use the option to "Convert Euler Rotation to Quaternion" on the pelvis and thighs, then the animation appears correct: http://edt.oni2.net/TRAMS/WalkQT.wmv  However, when importing a converted animation back to Oni, you get this result: http://edt.oni2.net/TRAMS/WalkOni.wmv
  at (wrapper delegate-invoke) System.MulticastDelegate:invoke_Vector2_single[]_int (single[],int)
  at Oni.Geometry.DaeConverter.CompressDuplicates[Vector2] (Oni.Geometry.Dae.GeometryInput input, System.Collections.Generic.List`1 list,   System.Collections.Generic.Dictionary`2 index, Oni.Func`3 elementReader) [0x00000]
  at Oni.Geometry.DaeConverter.FromDaeGeometry (Oni.Geometry.Dae.Geometry daeGeometry, Boolean createNormals, Boolean createShell, Single shellOffset) [0x00000]
  at Oni.Geometry.BodyImporter.ReadBodyPartsRecursive (Oni.Geometry.Dae.Node node, System.Collections.Generic.List`1 list) [0x00000]
  at Oni.Geometry.BodyImporter.ReadBodyParts (Oni.Geometry.Dae.Scene scene) [0x00000]
  at Oni.Geometry.BodyImporter.Import (System.String filePath, System.String outputDirPath) [0x00000]
at Oni.Program.CreateBody (System.String[] args) [0x00000]
  at Oni.Program.Main (System.String[] args) [0x00000]  (1)


EDIT: Upon more investigation, it appears the problem is from an update to Cheetah3D4.6, when I export the file from Cheetah3d4.4, I do not get the error message.  If you're interested, here are the 3 collada files of Konoko generic, no changes http://edt.oni2.net/OniSplit/TRBSkonoko.zip (OniSplit export, Cheetah3D4.4 and Cheetah3D4.6, both Cheetah versions were exported first as FBX, then converted to DAE by FBXconverter) [[User:EdT|EdT]] 02:19, 29 September 2008 (CEST)
When a TRAM is imported to XSI, to "unwrap" a model from the default animation state, the right thigh is rotated 180 on the X axis and -180 on the Z axis, the left is rotated -180 on the X and -180 on the Z axis. Somehow, from this starting point, whenever XSI moves the thigh from a negative to a positive angle (or in the case of this example from positive to negative), the part would rotate the long way around as shown here: http://edt.oni2.net/TRAMS/ThighXZaxis.wmv


2 quick answers:
One workaround is to insert keyframes to cause the animation to rotate in the correct direction.


:*IGSt space - you need to add a xml:space="preserve" attribute for those Text elements:
I found another approach that seems to work, if you are making an animation from scratch. That is to rotate the thighs down 180 on the Y axis.  So far in my testing, there are no odd rotations: http://edt.oni2.net/TRAMS/ThighYaxis.wmv


  <Text xml:space="preserve"> </Text>
The Striker DAE files and the XSI scene files are here: http://edt.oni2.net/TRAMS/TRAMfiles.zip


:I'll try to make OniSplit add that automatically in the next version, I didn't know that there are such cases.
[[User:EdT|EdT]]


:*Cheetah 3D4.6 - the coresponding Collada files looks "corrupted". Basically it contains wrong texture coordinate indices I suspect that there is a bug somewhere but not in OniSplit.
I'm still unsure how the XZ animation was produced. There's a keyframe (for the Z rotation of left_thigh) that causes this. It's value is 135 while all the other keyframes for Z are well below 0 (-150..-180). If you move that keyframe to something like -215 then the animation works fine. Or so it appears to me...  


[[User:Neo|Neo]]
[[User:Neo|Neo]]
::Ed, since there's a converter involved, please provide the FBX that are output by Cheetah. Either the converter does everything correctly, and the bad UV indices come from the FBX (which should be reported to Cheetah's dev); or the FBX confuses the heck out of the converter in a more subtle way (this can be a bug of either program). Not that we are guaranteed to find out the reason, but letting us have the FBX would help the investigation. --[[User:Geyser|geyser]] 21:47, 13 October 2008 (CEST)
:::geyser, [http://edt.oni2.net/OniSplit/TRBSkonoko.zip  here are the files] this is what the developer said about the problem "Although the FBX SDK imports the Cheetah3D FBX files correctly the Collada exporter messes them up. But the Collada support in the FBX SDK is a big problem since years and things are improving just slowly"


:::Also, is there a table or chart that shows the relationship between the BSL name and the function name? For example chr_set_class -> _iSetCharacterClassI want to see if I can patch the game myself, but I have no idea what function would correspond to such things as sc_bind_f2, co_display, wp_kickable, door_ignore_locks and so on. Thanks [[User:EdT|EdT]] 01:26, 14 October 2008 (CEST)
:That's true about changing the keyframe to -215, however, for all the TRAMs exported from Oni, the number for the rotations are always less than 180 or -180When the thigh is positioned in front of the body, the rotation on the Z axis is negative, between the range of -0.x to -179.x and when it is positioned behind the body, the rotation number is positive, between the range of 0.x to 179.x. So my XZ animation was reflecting that aspect. [[User:EdT|EdT]]


::::FBX: The FBX converter crashes while trying to convert that file to Collada. Softimage XSI loads the file but the exported Collada files contains no texture coordinates. So, I don't know what's going on, looks like the FBX file is bad.
::Ah, I didn't think about that. I don't think it matters if those angles are between -180..180 or not, I haven't seen any problems while trying to import the animation with -215. [[User:Neo|Neo]]
::::BSL: There is no such table. The best bet is picking them from the PC exe disassembly :). [[User:Neo|Neo]]


:::::FBX, its no problem, I can use the older version of Cheetah3D.
:::Then my question is, would it be possible to program OniSplit one day, so that it can produce a TRAM DAE that will import into XSI without any of those odd rotations of the pelvis and thighs? Or for OniSplit to import a TRAM DAE that was converted from Euler to Quaternion rotation? It will be much easier to modify existing TRAMs without having to deal with those odd rotations. Thanks [[User:EdT|EdT]]
:::::BSL, can you recommend a PC disassembler, I can use it under VirtualPC.  Also, can you show me how find the link between the BSL function like sc_bind_f2 and the function name in the engine using the disassembler.  Like the saying goes "Give a man a fish, he eats for a day. Teach a man to fish and he eats for a lifetime" Please teach me how to fish :-) [[User:EdT|EdT]] 16:09, 14 October 2008 (CEST)


:::::FBX - I don't know, I saw all kinds of problems with all kinds of 3D file formats. Basically I know of no file format or application that's 100% guaranteed to work properly.
::::TRAM DAE: yes, I think so. I have an idea though I've yet to test it. Euler to Quaternion: I don't know why that doesn't work, I'll check. In theory there should be no problem. [[User:Neo|Neo]]
:::::BSL - For PC disassembling you can use the [http://www.hex-rays.com/idapro/idadownfreeware.htm free version of IDA]. See [http://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniPC|_idb49.zip here] for my IDA database file. I don't think you can bind sc_bind_f2 easily (compared to others). It's a string variable and nothing in the Mac exe uses them so nobody calls the function that's supposed to register string variables. [[User:Neo|Neo]]
::::Found another solution (in XSI): use "Make rotation keys continuous" (in the same menu as Euler to Quaternion). [[User:Neo|Neo]]
:::::I tested the it, however, TRAMs converted that way do not appear correctly in Oni: http://edt.oni2.net/TRAMS/WalkRot.wmv files:http://edt.oni2.net/TRAMS/TRAMfiles2.zip  [[User:EdT|EdT]]
:::::Not to say that this is the only problem but... you're .dae files for left and right are identical :) [[User:Neo|Neo]]
::::::"The Make rotation keys continuous"is working great, no problems. Except for the stupid user error with the Striker's walk... lol [[User:EdT|EdT]]
::::::: Googled a possible solution and fitted it to one method. I have already checked it for some quaternions, which should result in euler angles, which contains values greater than 180 degrees, and it works fine. Here it is:
    public static Vector3 FromQ2(Quaternion q1)
    {
        float sqw = q1.w * q1.w;
        float sqx = q1.x * q1.x;
        float sqy = q1.y * q1.y;
        float sqz = q1.z * q1.z;
        float unit = sqx + sqy + sqz + sqw; // if normalised is one, otherwise is correction factor
        float test = q1.x * q1.w - q1.y * q1.z;
        Vector3 v;
        Func<float, float> NormalizeAngle = new Func<float, float>(angle =>
        {
            while (angle > 360)
                angle -= 360;
            while (angle < 0)
                angle += 360;
            return angle;
        });
        Func<Vector3,Vector3> NormalizeAngles = new Func<Vector3,Vector3>(angles =>
        {
            angles.x = NormalizeAngle(angles.x);
            angles.y = NormalizeAngle(angles.y);
            angles.z = NormalizeAngle(angles.z);
            return angles;
        } );
        if (test > 0.4995f * unit)
        { // singularity at north pole
            v.y = 2f * Mathf.Atan2(q1.y, q1.x);
            v.x = Mathf.PI / 2;
            v.z = 0;
            return NormalizeAngles(v * Mathf.Rad2Deg);
        }
        if (test < -0.4995f * unit)
        { // singularity at south pole
            v.y = -2f * Mathf.Atan2(q1.y, q1.x);
            v.x = -Mathf.PI / 2;
            v.z = 0;
            return NormalizeAngles(v * Mathf.Rad2Deg);
        }
        Quaternion q = new Quaternion(q1.w, q1.z, q1.x, q1.y);
        v.y = (float)Math.Atan2(2f * q.x * q.w + 2f * q.y * q.z, 1 - 2f * (q.z * q.z + q.w * q.w));    // Yaw
        v.x = (float)Math.Asin(2f * (q.x * q.z - q.w * q.y));                            // Pitch
        v.z = (float)Math.Atan2(2f * q.x * q.y + 2f * q.z * q.w, 1 - 2f * (q.y * q.y + q.z * q.z));      // Roll
        return NormalizeAngles(v * Mathf.Rad2Deg);
    }
p.s. sorry, not found any code tags or something like that.
p.s.s. Mathf.Rad2Deg must be 57.2958f. other Mathf stuff is similar to Math
p.s.s.s anyway, looks like the root of evil is not in quaternion -> euler conversion. i will try to investigate that.
[[User:TwinkerTinker|6opoDuJIo]]


::::::Thanks for the link and the database, but now I need the fishing instruction :-)  Can you show me how I can find the engine function related to the BSL function.  I tried a text search for chr_focus, got the results, but I could not find out how it pointed to _SetMainCharacter.  Once I see it in the PC engine, then I will look for it in the Mac engine.  [[User:EdT|EdT]] 07:30, 15 October 2008 (CEST)
----
:::::::Do a text search for "chr_focus" starting from the beginning. The first one you come up with should be a long list of console variables. Now look two lines below. You see "_SetMainCharacter" now? Double click it, and you can get the offset. [[User:Gumby|Gumby]] 08:21, 15 October 2008 (CEST)
::::::::Smacks head! Thanks [[User:EdT|EdT]] 21:58, 15 October 2008 (CEST)


Hi Neo,


I'm trying to port my Oni from PC to Mac by recombining the *.oni file at the new location. This works fine in general but SNDD give me an error. (I could play without sound but wouldn't like to.)
I have thought of adding a point to your todo list if you don't mind. Since the throw target is sort of reversed played in Oni (body rotated by 180 degrees, reversed movement, if I remember correctly), it would come handy if Onisplit can reverse it. Doing it in XSI would be a load of unnecessary work each time. Onisplit could easily recognize this special animation in the XML tags (<Flag>... ThrowTarget ...</Flag>). --[[User:Paradox-01|Paradox-01]] 15:21, 29 March 2010 (UTC)


Here's the error I faced:
----
 
Here's a mystery [which has been solved, see edits below this one]: what is wrong with Oni's sound occlusion with 44Khz sounds in Windows (and possibly all occlusion on Macs)? Here are two alternate versions of a package: <nowiki>http://iritscen.oni2.net/temp/06000MissingSoundsNoOcc.zip</nowiki> (dead link) and <nowiki>http://iritscen.oni2.net/temp/06000MissingSoundsOcc.zip</nowiki> (dead link). This package simply adds a sound to the gears at the end of Science Prison. There are probably any number of ways to test for this issue, but this is how I noticed the problem, so I can vouch for its reproducibility.
System.IO.InvalidDataException: File/Users/.../Desktop/Oni/Oni/GameDataFolder/level0_Final/SNDDzomshin_amb_loop.aif.oni cannot be imported due to conflicting template checksums
# Install the Occ version of the package. This uses 22Khz sound.
  at Oni.InstanceFileWriter.AddDescriptor (Oni.InstanceDescriptor descriptor) [0x00000]
# Load Science Prison SP1 so there's no music or enemies around, and do "chr_location 0 676.3 64.7 -1898.3". You're now on top of the gears.
  at Oni.InstanceFileWriter.AddDescriptors (System.Collections.Generic.List`1 descriptors, Boolean removeDuplicates) [0x00000]
# Run into one of the nearby rooms with windows. The sound comes from the point you teleported to, so position yourself so the "ray" from the sound can reach you through a window. If you are standing with part of the room's wall in the way, the sound may cut out completely, which you don't want.
  at Oni.OniImporter.Import (Oni.FileManager fileManager, System.String inputDirPath, System.String filePath, Int64 targetTemplateChecksum) [0x00000]
# Listen to the sound. Isn't it soothing? Now shoot the glass out (the M. Bow is a nice choice, it's quiet so you can hear the gears more clearly). The sound should get louder. You can hear this in my movie <nowiki>http://iritscen.oni2.net/temp/GearsTestWindows.mp4</nowiki> (dead link) (though the gears sound was distorted at the time because I didn't set the .grp properly, that's besides the point in this case).
  at Oni.Program.Import (System.String[] args) [0x00000]
# Now replace the Occ package with the NoOcc package and install it. This one uses 44Khz sound.
  at Oni.Program.Main (System.String[] args) [0x00000]  (1)
# Performing the same test, you should hear the gears at the same volume through glass as without the glass in the way. You can hear this issue in my movie <nowiki>http://iritscen.oni2.net/temp/GearsTestMac.mp4</nowiki> (dead link). Obviously in the Mac test I was using 22Khz sound, and yet I experienced the same issue. I suspect something was changed in the occlusion code between the Windows and Mac releases, perhaps in tandem with the removal of 44Khz sound support, that glommed the Windows 44Khz bug onto the Mac 22Khz sound code.
 
Any idea how to avoid/fix this?


--[[User:Paradox-01|Paradox-01]] 15:19, 19 October 2008 (CEST)
Now, is it definitely a problem with Oni? I guess it is if we're sure that the sounds and .grp I provided are formatted and imported correctly. Or perhaps I'm totally mixed up here and don't know what I'm talking about. I've never done sound work before in Oni. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 15:36, 25 April 2013 (CEST)


Dox, the SNDD format is different on Mac and PC. If you want to use PC sounds on a Mac, you need to rip them as WAV and reencode them in the Mac format. OniSplit doesn't import sounds Yet(TM). P.S. Serves you right for getting a Mac ^_^ --[[User:Geyser|geyser]] 16:04, 19 October 2008 (CEST)
: Iritscen: Try your test again with the command sound_show_debug=1 you will see a list of sounds and the sound level for each one. When you are in front of the gears the level is 1 for gears, gears.aif .  Then move into one of the rooms behind the glass, the sound level will drop to around .6 or .7 depending on how far away you are.  Shoot out the glass and then the sound level will return to 1.[[User:EdT|EdT]] ([[User talk:EdT|talk]]) 17:02, 25 April 2013 (CEST)


Ja ja, lach ruhig. ^_^ But still I can use the advantages of both systems now. --[[User:Paradox-01|Paradox-01]] 16:21, 19 October 2008 (CEST)
::D'oh. I was wondering if I should have put this on Paradox's page but I felt that it was probably an Oni bug and I shouldn't distract 'dox anymore. I guess you would have had a simple solution to the problem no matter where I put it, EdT. So here's what happened: the NoOcc package has a custom .grp so that I can specify "2" channels, AKA 44Khz sound, since Oni's .grp expects 22Khz. What I had forgotten that I also tried to turn up the volume of the gears noise by setting the .grp's Volume to 2 instead of 1. Because a sound's maximum actual volume in Oni is 1, what happens with a >1 volume setting is that a sound will reach 100% volume from farther away than if the sound was set to a volume of 1. Because I was standing within the >1 apparent volume range of the NoOcc package's louder gears, I couldn't hear any difference in sound volume when a window got in the way. That's because the volume was still greater than 1 even though the sound was in fact being occluded from say, 1.9 to 1.4.
::Well, I learned something about sound today! Sorry for cluttering your talk page unnecessarily, Neo (I know you won't be seeing this until the weekend anyway). The funny thing is that I just got done telling someone on the forum about sound_show_debug, but I had no idea that the numbers in the left column were apparent volume so I didn't think of using the debug display on my package. Well, thanks EdT, at least I know everything is working properly. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 18:06, 25 April 2013 (CEST)


----
----
So, uh, watching the '99 trailer, I am scoping out the realtime shadows (Cf. the throwing clip at 1:17 if you want a clear example). Of course it is a rough-looking implementation because the tech at the time no doubt could only handle those coarse meshes, but it looks like both blood and shadows ran off this system and then it was replaced with the simple dark-spot shadows that we have now. I am sure you/geyser must have noticed this by now, but I don't see where it has been discussed. So... this capability is not still in the code, is it? Also, a second question: the shadows that objects cast onto the floor in-game: where do they come from? Some of them are pretty wacky, and I personally have a hard time believing they are being mapped dynamically by the engine based upon the nearby lighting. Examples include the crates in the Warehouse. --[[User:Iritscen|Iritscen]] 04:51, 21 October 2008 (CEST)
Hi Neo,
:Iritscen, I always assumed that blood was a particle effect. [[User:Gumby|Gumby]] 07:09, 21 October 2008 (CEST)
 
:Adding some more interesting points, in the PC I found these:
0001:001073F0      _ONrMotoko_GraphicsQuality_CharacterPolygonCount
0001:00107440      _ONrMotoko_GraphicsQuality_RayCastCount
0001:00107490      _ONrMotoko_GraphicsQuality_NumDirectionalLights
0001:001074E0      _ONrMotoko_GraphicsQuality_RayCount
0001:00107530      _ONrMotoko_GraphicsQuality_SupportTrilinear
0001:00107540      _ONrMotoko_GraphicsQuality_SupportCosmeticCorpses
0001:00107550      _ONrMotoko_GraphicsQuality_SupportHighQualityCorpses
0001:00107560      _ONrMotoko_GraphicsQuality_NeverUseSuperLow
 
:But the Mac has a few more:
0001:00072C04      _ONrMotoko_GraphicsQuality_CharacterPolygonCount
0001:00072C7C      _ONrMotoko_GraphicsQuality_RayCastCount
0001:00072CF4      _ONrMotoko_GraphicsQuality_NumDirectionalLights
0001:00072D6C      _ONrMotoko_GraphicsQuality_RayCount
0001:00072DE4      _ONrMotoko_GraphicsQuality_SupportShadows
0001:00072E10      _ONrMotoko_GraphicsQuality_SupportTrilinear
0001:00072E3C      _ONrMotoko_GraphicsQuality_SupportReflectionMapping
0001:00072E68      _ONrMotoko_GraphicsQuality_SupportHighQualityTextures
0001:00072E94      _ONrMotoko_GraphicsQuality_SupportCosmeticCorpses
0001:00072EC0      _ONrMotoko_GraphicsQuality_SupportHighQualityCorpses
0001:00072EEC      _ONrMotoko_GraphicsQuality_NeverUseSuperLow
0001:00072F18      _ONrMotoko_GraphicsQuality_HardwareBink
 
Any ideas on how to test the SupportShadows, SupportHighQualityTextures, SupportReflectionMapping?
 


:SupportShadows, SupportHighQualityTextures and SupportReflectionMapping have the same code as SupportCosmeticCorpses so the compiler/linker axed them and kept only one copy of the code.
I've tried a couple of OniSplit commands but I couldn't get some to work with latest public version (0.9.94.0). The commands are the follow:


:SupportHighQualityTextures is used by a piece of code that doesn't appear to exist on PC. It seems that if the graphics quality level is set to low it will ignore the texture mipmaps.
'''Conversion of ONWC > OBJ and DAE:'''


:I saw that trailer and its shadows but the question is if that's real-time, in-game graphics or not. There's no trace of such thing in any of the executables I saw. Besides I kind of doubt it that it was possible to get reasonable fast shadows using OpenGL 1.x and the graphics hardware available at that time (and don't forget that Oni is anyway a CPU hog). Halo PC which came out in 2003 has nice (optional) shadows but there's no chance to get it to work on video cards Oni ran on.  
  -extract:obj outputdir input_ONWC.oni


:Shadows as we see them in Oni are just decals and that's why sometimes they show up in unexpected places like those crates, they're simply "projected" to nearby quads. Try firing the sbg to the corner of a room and you'll see what I'm talking about. And there isn't any "nearby lighting" either. All the light in Oni is static, backed into the environment quads by using vertex colors. There may be some static lighting to avoid flat looking characters but that's pretty much all of it.
  -extract:dae outputdir input_ONWC.oni
 
[[User:Neo|Neo]]


both execute with sucess but don't generate output.


Interesting, I had no idea the object shadows were decals. But then, what determined their placement? Is it fixed as part of the level data, or based on some calculation?
'''Conversion of OBJ > M3GM:'''


P.S.: I actually do think those character shadows were in-game and real-time, but that's just my own opinion. For one thing, the game gets choppy here and there in that footage, such as the throw I mentioned at 1:17. If it can get choppy, it has to be recorded in real-time, not pre-rendered. And if it's real-time, some machine, somewhere was producing that footage. That doesn't mean that it was running acceptably; there are no shots of more than two or three characters onscreen, so we don't know if performance was bombing because of the shadows and they took them out (and they are straight-down anyway, not being calculated with respect to lighting, so that would have made it simpler). A bit of research indicates that games were starting to use dynamic shadows not long after that point in time, although it was surprisingly hard to get any solid answers about what games debuted with shadow mapping, and in what years. Oh well, this is all just a talking point now, it's not something we can do anything about.
  -create:m3gm outputdir input.obj


--[[User:Iritscen|Iritscen]] 16:28, 21 October 2008 (CEST)
I get the exception:
:It seems to me that Iritscen and Neo mean different things when it comes to "those crates" in the Warehouse. The decal mentioned by Neo is just the round shadow texture, projected downwards from the player's position onto all non-vertical quads (even those flagged as walls), which looks weird when the quad is a nearly vertical wall. Iritscen's question, however, seems to be about "shadows cast by objects", in this case, by the crates themselves. As Neo said, environment lighting in Oni starts and ends with baked vertex colors, which were computed from light sources; this is never very accurate for coarse geometry, and the exact algorithm that was used is unknown: we don't even know for sure if the vertex colors were authored in Max/AutoCAD or if they were generated by Oni-specific code. Triangulated meshes have real-time Gouraud shading instead (and env mapping).
  System.ArgumentOutOfRangeException: O ¡ndice estava fora do intervalo. Tem de ser nÆo negativo e inferior ao tamanho da colec?Æo.
:As for the shadows in the 1999 trailer, they were definitely ingame stuff. Like Iritscen says, they're just vertical projections of the character's body. One solution was to draw a round shadow for every one of the 19 bones, but I think what we see is essentially a set of decals based on the dynamic pathfinding grid. I wouldn't be surprised if those shadows used the same code as the pathfinding algorithms: if the body of a character is detected above a certain grid square, that square is flagged as an obstacle ''and'' a shadow decal is drawn on it. As for why those shadows were scrapped: they're not too distractive in the trailer (which is why I hadn't noticed them until now; honest), but since they're based on an axis-aligned grid, they'd look awful in a lot of situations. I'm glad we have a smooth, round shadow now, not some dark tiles flashing in and out as we move.
  Nome do par?metro: index
::[[User:Geyser|geyser]] 17:12, 21 October 2008 (CEST)
  em System.ThrowHelper.ThrowArgumentOutOfRangeException()
:::Thanks, geyser, that was indeed what I was asking about in question 2, shadows on objects like crates. Your answer makes sense, as to why the shadows are so crappy ^_^. Strange that Oni's lighting system seems so much more primitive than Marathon's from 7 years earlier.
  em Oni.Dae.IO.ObjReader.ReadVertices(String[] tokens)
:::Just an FYI on the real-time shadow topic: it looks like they were using shadow mapping, which as far as I understand, is the generation of a new texture that overlays a surface. That texture, until recent advancements in processor speed, needed to be very low-res, which is why the trailer shadows look like a collection of fuzzy squares; it's because it's a very "blown-up" texture. It's true that is doesn't seem to add much to the game (esp. versus the CPU cost it must have meant), but human shadows are basically round blobs anyway at that angle so the current "spot decal" shadows make little difference; imagine what it would have done for the Iron Demon, though....<br>
  em Oni.Dae.IO.ObjReader.ReadFace(String[] tokens)
:::--[[User:Iritscen|Iritscen]] 18:01, 21 October 2008 (CEST)
  em Oni.Dae.IO.ObjReader.ReadObjFile(String filePath)
::::Maybe you should have provided a screenshot for "question 2", because at this moment neither I nor Neo have a clear idea of what precise crappy shadow you're looking at. Same for Marathon's lighting: what is so elaborate about it, really? If it's flawless, it's only because the geometry (and lighting) of Marathon levels is much more primitive than what we have in Oni, IMHO. As far as I can tell, it's the same flat shading as in Doom/DarkForces/DukeNukem3D/whatever (with amounts of lighting defined per polygon, not per vertex).
  em Oni.Dae.IO.ObjReader.ReadFile(String filePath)
::::As for "question 1", you can call those character shadows shadow-mapped if you want, but as far as I can tell they have nothing to do with textures and UVs generated at runtime (which is what shadow mapping is about). To me, it definitely looks like the sphere tree of the character is projected downwards onto a grid, and the grid squares are then shaded with decals placed at fixed positions, switched on and off. The alpha amount of the squares is apparently not proportional to the amount of overlap: this allows for an evenly shaded interior, but the edge is fuzzy. The grid is quite coarse throughout the trailer, but it is much finer in the multiplayer arena at 1:37, for example: in that scene you can also see that since the projection is that of an upright sphere tree, for increasingly fine grids the shadow will look more and more like a circle. In that sense, the single dynamic decal that we have now is a consistent improvement over whatever those "shadow maps" were: it looks just like a super-high-resolution "shadow map", only smoother. Also note that the Iron Demon doesn't have a shadow at all in that trailer, so whatever shadow map was being computed from its sphere tree, it probably sucked.
  em Oni.Motoko.GeometryImporter.Import(String filePath, String outputDirPath)
:::::[[User:Geyser|geyser]] 19:19, 21 October 2008 (CEST)
  em Oni.Program.ExecuteTasks(String[] args, String outputDirPath, Set`1 importedFiles, Queue`1 taskQueue)
::::::Not sure we really want an in-depth discussion about this on Neo's talk page, but if you like we can move it to somewhere else; for now I'll respond here, since you asked here...
  em Oni.Program.CreateGeneric(String[] args)
::::::*"What crappy shadows?" Any of them, pretty much. But if you need visual aids, let me ask you what the heck is going on [http://iritscen.oni2.net/temp/Oni-BadShadows1.jpg here], let me point out that many shadows are of [http://iritscen.oni2.net/temp/Oni-BadShadows2.jpg erratic shadiness and height], and some crates are lacking shadows completely in the back of that last shot. Also, count the things wrong [http://iritscen.oni2.net/temp/Oni-BadShadows3.jpg here]. Finally, Gumby contributed an example the other day: explain why the shadows move [http://iritscen.oni2.net/temp/Oni-BadShadows4.jpg towards the light] if they're not crappy. You yourself already acknowledged that the baked-in shadows were not good, so I can't understand your sudden puzzlement, but there ya go.
  em Oni.Program.Main(String[] args)
::::::*"As far as I can tell [etc. etc.]". As far as I can tell, you haven't been looking very hard. If you wanted to be lazy you could have just asked me on YIM for evidence, but I guess I have to take up more space on this page to answer the question you posted here: [http://iritscen.oni2.net/temp/Marathon-GoodShadows1.jpg these lights] [http://iritscen.oni2.net/temp/Marathon-GoodShadows2.jpg are dynamic]. Some lights even flicker in and out, with the expected changes in shadowing. And even though this is from the OpenGL-powered port, they looked exactly the same in 1994 when the game came out. Now, it's true that those are dynamic lights, not dynamic shadows, and they are in a hard-edged style not a softened style, but I just wanted to illustrate how much nicer Marathon's interplay of light and darkness is than Oni's. My question was why Oni couldn't do those sorts of calculations dynamically too. Don't jump all over me.
::::::*Re: How the shadow mapping works. We are saying close to the same thing here. I don't dispute/care how the shadows are calculated from the characters' models, I just think they are generated on-the-fly, not being applied as decals. Decals are fixed images stored in a resource file, whereas these look more like shaded boxes being filled in on a grid using vertices (also you called our current shadow spot "dynamic", and it's the opposite, it's static). It would be very non-standard to use static decals for shadow mapping, but whatever. I don't argue Oni would have looked better as it was back then. If we could bring back that technology from within the code (which we probably can't, this is just a hypothetical sentence so don't flip out), then we could probably also increase the grid resolution and make it look nicer; otherwise it is just something I pointed out for the sake of pointing it out. And it's true that the ID didn't have the shadows, that's interesting. But I wouldn't automatically assume it looked crappy just because they didn't show it. Let's go a little easier on the cynicism pedal, now.
::::::--[[User:Iritscen|Iritscen]] 21:30, 21 October 2008 (CEST)


:::::::*Hahaha, calm down guys, don't cut each other's throats on my talk page.  
Could these be fixed? Thanks. [[User:Script 10k|Script 10k]] ([[User talk:Script 10k|talk]]) 22:07, 3 January 2014 (CET)
:::::::*Yeah, Oni lighting/shading/"shadowing" pretty much sucks. Marathon has some sort of dynamic lighting, Quake II has both dynamic lighting and lightmaps (quite good ones for those times) while Oni only has static vertex shading which results in those dubious looking shadows Iritscen sees. Why? I really don't know. Maybe because neither Jason Jones or John Carmack worked on Oni, maybe because of the many large open spaces Oni has (both Marathon and Quake II featured mostly "tunnel" style worlds, I don't think there's a place in any of those that can be compared with the lab level for example).
:::::::*Character shadows & shadow mapping: I have to review that movie but I doubt it that "decent" shadow mapping was possible at that time using a "normal" computer and as I said, there's absolutely no trace of such a thing in the executable.
:::::::[[User:Neo|Neo]]


----
----
==Large textures==
Hi Neo, do you still stop by the wiki? Not sure if you will see this. I sent you an email at what I'm pretty sure is your Yahoo! address, but I don't know if you still check that email, and it doesn't seem that you use Yahoo! Messenger anymore. I'm trying to get back in touch with you to ask you some questions about OniSplit, etc. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 00:02, 27 September 2016 (CEST)
Hey Ed, remember that patch for larger textures that didn't work on Mac? Try doing it again and additionally change the following bytes:
 
  0x12200AF: replace 0x06 with 0x16 for 512x512 (or 0x46 for 1024x1024)
  0x12200B3: same as above
 
If 0x16 (0x46) fails try with 0x17 (0x47).
 
:[[User:Neo|Neo]]
 
Delorean in 1024x1024 glory:
 
http://edt.oni2.net/images/LGTexdelorean.jpg
 
:[[User:EdT|EdT]] 17:53, 21 October 2008 (CEST)


I just want to thank Neo and geyser for the work they've done on the Mac side, it doesn't really benefit you guys and yet you still help us out. Many thanks! --[[User:Iritscen|Iritscen]] 18:11, 21 October 2008 (CEST)
[[Category:Userspace]]

Latest revision as of 15:27, 7 May 2023

Talk page archives: #1 - #2 - #3 - #4 - #5

Hi Neo, In the latest oni split 0.9.55, there seems to be a problem with converting ONCC files, It fails to convert ONCC.xml files made by earlier to oni files .. says something about jump fields, the ONCC xml created by older versions are different from the ones created by this one, different fields <Jump Constants> and <Air Constants> instead of <Physics>, that would be ok we could switch to the new layout. However onisplit v.55 also fails to convert ONCC.xml it created back to oni. .. convert any ONCC.oni to xml, try to convert that xml back to oni, it fails.

2- It is also unable to convert a TRAM.oni file made from a dae by older versions back to xml : Operation is not valid due to current state of object. (containing QKEYS) while 0.941 is able to convert them.

reported by Samer on July 10 2011


Hi Neo, a bug has been ecountered by me in OniSplit's xml export. The bug applies on versions 0.9.50.0 and 0.9.52.0. If exported TRAM file has direct animation links, only the second direct link is written into XML file. The first direct link is ignored (is always an empty element).

This is an excerpt from KONCOMcomb_p_p XML file as created by OniSplit 0.9.52.0:

       <DirectAnimations>
           <Link />
           <Link>TRAMKONCOMcomb_p_p_k</Link>
       </DirectAnimations>

It should be:

       <DirectAnimations>
           <Link>TRAMKONCOMcomb_p_p_p</Link>
           <Link>TRAMKONCOMcomb_p_p_k</Link>
       </DirectAnimations>

Binary (*.oni) files contain both direct links. Exported XML files don't. Since usually only the first direct link is used, this bug poses quite a nuisance. Thank you in advance.

It might be that the binary (oni/exe) are corrupted. My version of TRAMKONCOMcomb_p_p.oni was correctly extracted with onisplit 52. --paradox-01 19:00, 8 July 2011 (CEST)

While I'm here I will take the chance to also ask something. I'm trying to create a combo. The animations work fine with animation type Kick, Kick2, Kick3 but not with KickRight, KrKr*, KrKrKr**. Could it be that those* animation types are dead? I hope you will find out what's wrong. --paradox-01 19:00, 8 July 2011 (CEST)

Loser: The problem more than likely was the fact that the TRAMKONCOMcomb_p_p_p.oni was not in the same directory as TRAMKONCOMcomb_p_p. To test, I removed TRAMKONCOMcomb_p_p_p.oni and got the same result as you did, added it back and got the correct output. OniSplit wants all the files to be in the same directory. EdT 23:36, 8 July 2011 (CEST)




Neo, do you think we can have something like a -nodeps argument added to OniSplit? We could use a way to prevent the program from automatically following all dependencies when exporting files like ONCCs to XML. --Iritscen 14:26, 6 July 2011 (CEST)

Oops, never mind, it sounds like this is already OniSplit's default behavior.... --Iritscen 16:24, 6 July 2011 (CEST)

Pathfinding issue fixed, though it seems to be still slightly off:

Junkyard PFG.jpg

There is still the issue of falling through the ground.

level files are here: http://edt.oni2.net/testlevel/junkyard.zip

EdT 03:14, 18 June 2011 (CEST)


Hi Neo,

I was able to create the pathfinding grids, however, they are offset from the geometry. Also, there is a spot where you will fall through the ground.

Junkyard.png

The bnv itself is correct:

Junkyard bnv.png

Here are my files: http://edt.oni2.net/testlevel/TestLevel.zip

EDIT: Tested OniSplit with the arena level data: http://mods.oni2.net/system/files/80200ArenaofHurt.zip Extracted the AKEV, then used create:akev to import the level. The pathfinding grids were offset from the geometry and there were areas where the player will fall through the floor.

EdT 01:03, 17 June 2011 (CEST)



Hi Neo, I have tried Your ".dae" to ".xml" animation importer. I keep getting message ".dae files cannot be imported as TRAM". Can you tell me please where is the problem? Thank you. --Loser 13:00, 11 July 2010 (UTC)

Hello, to import an animation you need an xml file and a dae file. If you try to export a TRAM to xml you get both files and when importing you need to provide the xml file, not the dae file. The dae file is referenced from inside the xml file (see the DaeImport element) Neo


New OniSplit version: OniSplit v0.9.52 (https://cid-639aa31296681bfe.skydrive.live.com/self.aspx/Oni/OniSplit/OniSplit%5E_v0.9.52.zip, dead link)

What's new:

  • When a TRBS file is exported to xml the geometry is exported to separate .dae files, one .dae file for each LOD
  • New -anim-body option. This allows a particular body (ONCC or TRBS) to be specified when exporting animations:
  onisplit -extract:xml out -anim-body:ONCCbarabus.oni TRAMsomething.oni
  • New -recurse option for the xml exporter. Have fun :)
  onisplit -extract:xml out -recurse ONCCbarabus.oni
  • Changed light color in the environment importer to white (it used to be blueish)
  • New -env-notxmp option. This prevents the automatic creation of TXMP files while importing the environment.
  • Made -normals work when importing TRBS from xml + dae files.

New OniSplit version: OniSplit v0.9.41

What's new:

  • fixed the Collada importer to work with 3DSMax exported files

New OniSplit version: OniSplit v0.9.40

What's new:

  • support for exporting/importing sound animations to/from xml files
  • better Collada export for environment
  • support for full color transparent textures (-format:bgra32 on the command line, ARGB8888 format in an xml file)
  • different (hopefully better) xml export format for animations (this one is actually from 0.9.38 but since that wasn't mentioned here...)
  • a more or less complete animation importer. This one deservers some notes:
-unlike other importers that produce .oni files this one produces and .xml file (similar to the one you get when exporting a TRAM)
when you do
 onisplit -create:tram target_dir animation.dae
in the target dir you'll get a TRAManimation.xml file.
You need to add some stuff to that file to make it actually work as an animation. In particular the animation type, from/to states and varient needs to be set.
-For all I know this works with animations exported from Oni and modified in Softimage. If you come up with a completly new animation it should work as long as the skeleton is similar to the one used in Oni.
-Note that the geometry that is present inside the Collada file is used to compute the "vertical extents" so it better be the same or close to the one the animation is intended for.
-The biggest problem are the attacks. While it's not difficult to add attacks to the xml file, computing the necessary "extents" is not going to be easy. I guess in the end I'll have to add some command to OniSplit to do it.
-Everything else that I forgot :)

Neo

New OniSplit version: OniSplit v0.9.37

What's new:

  • support for transparency in the environment importer


New OniSplit version: OniSplit v0.9.35

What's new:

  • conversion of recorded films (.dat binary files) to xml files that can be used to create FILM .oni files
   OniSplit film2xml out_dir film.dat

Neo

I get this error message using the command create:tram

 System.NotSupportedException: Invalid rotation axis {X:0 Y:0 Z:-1} for rotate transform in animation pelvis-node-ry
 at Oni.Totoro.AnimationDaeReader.FindRotations () [0x00000] 
 at Oni.Totoro.AnimationDaeReader.Import (System.String filePath, System.String outputDirPath) [0x00000] 
 at Oni.Program.CreateGeneric (System.String[] args) [0x00000] 
 at Oni.Program.Main (System.String[] args) [0x00000]  (1)

The dae files are here: http://www.filefront.com/14507129/dae.rar (dead link)

xml animation file here: http://www.filefront.com/14507115/ID%20walking.xaf (dead link)

Thanks EdT

Yep, caused by Z-up. I'll see what I can do.

Neo

Hi Neo,

When you have time, can you take a look at this:

TRBSproblem.jpg

When I use the latest FBX Converter 2010.2 to convert FBX to DAE, I get this problem. However, when I use an older version, it works fine. Here are the DAEs from both version: http://edt.oni2.net/temp/TRBSproblem.zip G2 is uses the new version, G1 uses the old.

Thanks EdT

Oh boy, the new converter uses matrix transforms instead of individual scale/rotate/translate transforms. I'll see what I can do...

Neo



The Iron Demon walks! Sorta...

You can see the video here: http://edt.oni2.net/ID/IDwalk.wmv

I converted the files from Bobbysoon (TRAMID_run1stepb.DAE, TRAMID_runstart.DAE, TRAMID_runstop.DAE) to xml. The XML gave the pelvis height as <Height>-2175.5</Height>, so I removed the negative and divided the height by 100. But as you can see, the model floats above the ground. Also, the velocity has some large numbers in the first part <Velocity>-4.076141 0</Velocity> I think that is the cause of the ID moving sideways not forward.

Files here: http://edt.oni2.net/ID/ID_Files.zip

EdT

Ha ha, that's going in my album of weird modding results. Anyway, I didn't even realize that animations were supposed to work yet, I thought we were waiting for an update to OniSplit. --Iritscen 14:33, 29 November 2009 (UTC)



Hi Neo,

Having problems converting DAEs to trams. I put all the files in a zip and included a ReadMe with the description of the errors. http://edt.oni2.net/temp/NeoTRAM.zip

I was trying to make new animations, whenever you have time, please take a look. Thanks EdT



Hmm... I just discovered that I can't export TXMPs from a .dat file to the PNG format. I am attempting to use the -extract:png command on a virgin .dat file. The -extract:tga options works fine, but the -extract:png option gives:

System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus --->  System.DllNotFoundException: gdiplus.dll
 at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)
 at System.Drawing.GDIPlus..cctor () [0x00000] 
 --- End of inner exception stack trace ---
 at System.Drawing.Bitmap..ctor (Int32 width, Int32 height, PixelFormat format) [0x00000] 
 at (wrapper remoting-invoke-with-check) System.Drawing.Bitmap:.ctor (int,int,System.Drawing.Imaging.PixelFormat)
 at Oni.Imaging.SysExporter.ExportInstance (Oni.InstanceDescriptor descriptor) [0x00000] 
 at Oni.Exporter.ExportInstanceList (System.Collections.Generic.List`1 descriptors) [0x00000] 
 at Oni.Exporter.Export (Oni.InstanceFileManager fileManager, System.String sourceFilePath, System.String filter) [0x00000] 
 at Oni.Program.ExtractTextures (System.String[] args) [0x00000] 
 at Oni.Program.Main (System.String[] args) [0x00000]

This occurred in both 0.9.38 and 0.9.41 on my Mac. I used to always extract TXMPs as TGA, so I don't know when this actually worked for me. --Iritscen 17:54, 2 January 2010 (UTC)

TGA always works because it's all done in OniSplit. For PNG/JPG I'm using the framework (.NET/Mono) and Mono seems to have a problem. Neo
I just tested it myself and I was able to extract all the textures from a virgin .dat file as PNG. I'm using the latest version 0.9.45 and the latest Mono framework. OSX 10.5.8 and 10.6.2 EdT
Okay, after many aborted attempts at updating mono (I was running 2.0.1) by building from source or using their binary installer, I realized that the installer was putting the files in some meaningless directory, and I ended up copying them to the right system directories, hoping I didn't overwrite libraries that were supposed to stay unchanged. Who knows what the consequences will be down the road for other stuff, but OniSplit now exports PNGs properly for me! --Iritscen 20:28, 3 January 2010 (UTC)

Observations of importing TRAMs to XSI.

Sometimes, imported TRAMs will have odd rotations mainly related to the pelvis and thighs. Here is one example, the Striker's walking TRAM: http://edt.oni2.net/TRAMS/WalkOS.wmv As you can see the pelvis and thighs are rotating in an odd fashion. This is due to euler vs quaternion rotations. To see it correctly in XSI, you can use the option to "Convert Euler Rotation to Quaternion" on the pelvis and thighs, then the animation appears correct: http://edt.oni2.net/TRAMS/WalkQT.wmv However, when importing a converted animation back to Oni, you get this result: http://edt.oni2.net/TRAMS/WalkOni.wmv

When a TRAM is imported to XSI, to "unwrap" a model from the default animation state, the right thigh is rotated 180 on the X axis and -180 on the Z axis, the left is rotated -180 on the X and -180 on the Z axis. Somehow, from this starting point, whenever XSI moves the thigh from a negative to a positive angle (or in the case of this example from positive to negative), the part would rotate the long way around as shown here: http://edt.oni2.net/TRAMS/ThighXZaxis.wmv

One workaround is to insert keyframes to cause the animation to rotate in the correct direction.

I found another approach that seems to work, if you are making an animation from scratch. That is to rotate the thighs down 180 on the Y axis. So far in my testing, there are no odd rotations: http://edt.oni2.net/TRAMS/ThighYaxis.wmv

The Striker DAE files and the XSI scene files are here: http://edt.oni2.net/TRAMS/TRAMfiles.zip

EdT

I'm still unsure how the XZ animation was produced. There's a keyframe (for the Z rotation of left_thigh) that causes this. It's value is 135 while all the other keyframes for Z are well below 0 (-150..-180). If you move that keyframe to something like -215 then the animation works fine. Or so it appears to me...

Neo

That's true about changing the keyframe to -215, however, for all the TRAMs exported from Oni, the number for the rotations are always less than 180 or -180. When the thigh is positioned in front of the body, the rotation on the Z axis is negative, between the range of -0.x to -179.x and when it is positioned behind the body, the rotation number is positive, between the range of 0.x to 179.x. So my XZ animation was reflecting that aspect. EdT
Ah, I didn't think about that. I don't think it matters if those angles are between -180..180 or not, I haven't seen any problems while trying to import the animation with -215. Neo
Then my question is, would it be possible to program OniSplit one day, so that it can produce a TRAM DAE that will import into XSI without any of those odd rotations of the pelvis and thighs? Or for OniSplit to import a TRAM DAE that was converted from Euler to Quaternion rotation? It will be much easier to modify existing TRAMs without having to deal with those odd rotations. Thanks EdT
TRAM DAE: yes, I think so. I have an idea though I've yet to test it. Euler to Quaternion: I don't know why that doesn't work, I'll check. In theory there should be no problem. Neo
Found another solution (in XSI): use "Make rotation keys continuous" (in the same menu as Euler to Quaternion). Neo
I tested the it, however, TRAMs converted that way do not appear correctly in Oni: http://edt.oni2.net/TRAMS/WalkRot.wmv files:http://edt.oni2.net/TRAMS/TRAMfiles2.zip EdT
Not to say that this is the only problem but... you're .dae files for left and right are identical :) Neo
"The Make rotation keys continuous"is working great, no problems. Except for the stupid user error with the Striker's walk... lol EdT
Googled a possible solution and fitted it to one method. I have already checked it for some quaternions, which should result in euler angles, which contains values greater than 180 degrees, and it works fine. Here it is:
   public static Vector3 FromQ2(Quaternion q1)
   {
       float sqw = q1.w * q1.w;
       float sqx = q1.x * q1.x;
       float sqy = q1.y * q1.y;
       float sqz = q1.z * q1.z;
       float unit = sqx + sqy + sqz + sqw; // if normalised is one, otherwise is correction factor
       float test = q1.x * q1.w - q1.y * q1.z;
       Vector3 v;
       Func<float, float> NormalizeAngle = new Func<float, float>(angle =>
       {
           while (angle > 360)
               angle -= 360;
           while (angle < 0)
               angle += 360;
           return angle;
       });
       Func<Vector3,Vector3> NormalizeAngles = new Func<Vector3,Vector3>(angles =>
       {
           angles.x = NormalizeAngle(angles.x);
           angles.y = NormalizeAngle(angles.y);
           angles.z = NormalizeAngle(angles.z);
           return angles;
       } );
       if (test > 0.4995f * unit)
       { // singularity at north pole
           v.y = 2f * Mathf.Atan2(q1.y, q1.x);
           v.x = Mathf.PI / 2;
           v.z = 0;
           return NormalizeAngles(v * Mathf.Rad2Deg);
       }
       if (test < -0.4995f * unit)
       { // singularity at south pole
           v.y = -2f * Mathf.Atan2(q1.y, q1.x);
           v.x = -Mathf.PI / 2;
           v.z = 0;
           return NormalizeAngles(v * Mathf.Rad2Deg);
       }
       Quaternion q = new Quaternion(q1.w, q1.z, q1.x, q1.y);
       v.y = (float)Math.Atan2(2f * q.x * q.w + 2f * q.y * q.z, 1 - 2f * (q.z * q.z + q.w * q.w));     // Yaw
       v.x = (float)Math.Asin(2f * (q.x * q.z - q.w * q.y));                             // Pitch
       v.z = (float)Math.Atan2(2f * q.x * q.y + 2f * q.z * q.w, 1 - 2f * (q.y * q.y + q.z * q.z));      // Roll
       return NormalizeAngles(v * Mathf.Rad2Deg);
   }

p.s. sorry, not found any code tags or something like that. p.s.s. Mathf.Rad2Deg must be 57.2958f. other Mathf stuff is similar to Math p.s.s.s anyway, looks like the root of evil is not in quaternion -> euler conversion. i will try to investigate that. 6opoDuJIo


Hi Neo,

I have thought of adding a point to your todo list if you don't mind. Since the throw target is sort of reversed played in Oni (body rotated by 180 degrees, reversed movement, if I remember correctly), it would come handy if Onisplit can reverse it. Doing it in XSI would be a load of unnecessary work each time. Onisplit could easily recognize this special animation in the XML tags (<Flag>... ThrowTarget ...</Flag>). --Paradox-01 15:21, 29 March 2010 (UTC)


Here's a mystery [which has been solved, see edits below this one]: what is wrong with Oni's sound occlusion with 44Khz sounds in Windows (and possibly all occlusion on Macs)? Here are two alternate versions of a package: http://iritscen.oni2.net/temp/06000MissingSoundsNoOcc.zip (dead link) and http://iritscen.oni2.net/temp/06000MissingSoundsOcc.zip (dead link). This package simply adds a sound to the gears at the end of Science Prison. There are probably any number of ways to test for this issue, but this is how I noticed the problem, so I can vouch for its reproducibility.

  1. Install the Occ version of the package. This uses 22Khz sound.
  2. Load Science Prison SP1 so there's no music or enemies around, and do "chr_location 0 676.3 64.7 -1898.3". You're now on top of the gears.
  3. Run into one of the nearby rooms with windows. The sound comes from the point you teleported to, so position yourself so the "ray" from the sound can reach you through a window. If you are standing with part of the room's wall in the way, the sound may cut out completely, which you don't want.
  4. Listen to the sound. Isn't it soothing? Now shoot the glass out (the M. Bow is a nice choice, it's quiet so you can hear the gears more clearly). The sound should get louder. You can hear this in my movie http://iritscen.oni2.net/temp/GearsTestWindows.mp4 (dead link) (though the gears sound was distorted at the time because I didn't set the .grp properly, that's besides the point in this case).
  5. Now replace the Occ package with the NoOcc package and install it. This one uses 44Khz sound.
  6. Performing the same test, you should hear the gears at the same volume through glass as without the glass in the way. You can hear this issue in my movie http://iritscen.oni2.net/temp/GearsTestMac.mp4 (dead link). Obviously in the Mac test I was using 22Khz sound, and yet I experienced the same issue. I suspect something was changed in the occlusion code between the Windows and Mac releases, perhaps in tandem with the removal of 44Khz sound support, that glommed the Windows 44Khz bug onto the Mac 22Khz sound code.

Now, is it definitely a problem with Oni? I guess it is if we're sure that the sounds and .grp I provided are formatted and imported correctly. Or perhaps I'm totally mixed up here and don't know what I'm talking about. I've never done sound work before in Oni. --Iritscen (talk) 15:36, 25 April 2013 (CEST)

Iritscen: Try your test again with the command sound_show_debug=1 you will see a list of sounds and the sound level for each one. When you are in front of the gears the level is 1 for gears, gears.aif . Then move into one of the rooms behind the glass, the sound level will drop to around .6 or .7 depending on how far away you are. Shoot out the glass and then the sound level will return to 1.EdT (talk) 17:02, 25 April 2013 (CEST)
D'oh. I was wondering if I should have put this on Paradox's page but I felt that it was probably an Oni bug and I shouldn't distract 'dox anymore. I guess you would have had a simple solution to the problem no matter where I put it, EdT. So here's what happened: the NoOcc package has a custom .grp so that I can specify "2" channels, AKA 44Khz sound, since Oni's .grp expects 22Khz. What I had forgotten that I also tried to turn up the volume of the gears noise by setting the .grp's Volume to 2 instead of 1. Because a sound's maximum actual volume in Oni is 1, what happens with a >1 volume setting is that a sound will reach 100% volume from farther away than if the sound was set to a volume of 1. Because I was standing within the >1 apparent volume range of the NoOcc package's louder gears, I couldn't hear any difference in sound volume when a window got in the way. That's because the volume was still greater than 1 even though the sound was in fact being occluded from say, 1.9 to 1.4.
Well, I learned something about sound today! Sorry for cluttering your talk page unnecessarily, Neo (I know you won't be seeing this until the weekend anyway). The funny thing is that I just got done telling someone on the forum about sound_show_debug, but I had no idea that the numbers in the left column were apparent volume so I didn't think of using the debug display on my package. Well, thanks EdT, at least I know everything is working properly. --Iritscen (talk) 18:06, 25 April 2013 (CEST)

Hi Neo,

I've tried a couple of OniSplit commands but I couldn't get some to work with latest public version (0.9.94.0). The commands are the follow:

Conversion of ONWC > OBJ and DAE:

  -extract:obj outputdir input_ONWC.oni
  -extract:dae outputdir input_ONWC.oni

both execute with sucess but don't generate output.

Conversion of OBJ > M3GM:

  -create:m3gm outputdir input.obj

I get the exception:

  System.ArgumentOutOfRangeException: O ¡ndice estava fora do intervalo. Tem de ser nÆo negativo e inferior ao tamanho da colec?Æo.
  Nome do par?metro: index
  em System.ThrowHelper.ThrowArgumentOutOfRangeException()
  em Oni.Dae.IO.ObjReader.ReadVertices(String[] tokens)
  em Oni.Dae.IO.ObjReader.ReadFace(String[] tokens)
  em Oni.Dae.IO.ObjReader.ReadObjFile(String filePath)
  em Oni.Dae.IO.ObjReader.ReadFile(String filePath)
  em Oni.Motoko.GeometryImporter.Import(String filePath, String outputDirPath)
  em Oni.Program.ExecuteTasks(String[] args, String outputDirPath, Set`1 importedFiles, Queue`1 taskQueue)
  em Oni.Program.CreateGeneric(String[] args)
  em Oni.Program.Main(String[] args)

Could these be fixed? Thanks. Script 10k (talk) 22:07, 3 January 2014 (CET)


Hi Neo, do you still stop by the wiki? Not sure if you will see this. I sent you an email at what I'm pretty sure is your Yahoo! address, but I don't know if you still check that email, and it doesn't seem that you use Yahoo! Messenger anymore. I'm trying to get back in touch with you to ask you some questions about OniSplit, etc. --Iritscen (talk) 00:02, 27 September 2016 (CEST)