User talk:Neo: Difference between revisions

From OniGalore
Jump to navigation Jump to search
No edit summary
(cleanup)
Line 1: Line 1:
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)


[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.
  at Oni.Vector2.FromArray (System.Single[] values, Int32 index) [0x00000]
  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)
2 quick answers:
:*IGSt space - you need to add a xml:space="preserve" attribute for those Text elements:
  <Text xml:space="preserve"> </Text>
:I'll try to make OniSplit add that automatically in the next version, I didn't know that there are such cases.
:*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.
[[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 -> _iSetCharacterClass.  I 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)
::::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.
::::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.
:::::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.
:::::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]]
::::::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)
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.)
Here's the error I faced:
System.IO.InvalidDataException: File/Users/.../Desktop/Oni/Oni/GameDataFolder/level0_Final/SNDDzomshin_amb_loop.aif.oni cannot be imported due to conflicting template checksums
  at Oni.InstanceFileWriter.AddDescriptor (Oni.InstanceDescriptor descriptor) [0x00000]
  at Oni.InstanceFileWriter.AddDescriptors (System.Collections.Generic.List`1 descriptors, Boolean removeDuplicates) [0x00000]
  at Oni.OniImporter.Import (Oni.FileManager fileManager, System.String inputDirPath, System.String filePath, Int64 targetTemplateChecksum) [0x00000]
  at Oni.Program.Import (System.String[] args) [0x00000]
  at Oni.Program.Main (System.String[] args) [0x00000]  (1)
Any idea how to avoid/fix this?
--[[User:Paradox-01|Paradox-01]] 15:19, 19 October 2008 (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)
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)
----
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)
: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.
: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.
: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.
: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.
[[User:Neo|Neo]]
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?
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.
--[[User:Iritscen|Iritscen]] 16:28, 21 October 2008 (CEST)
: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).
: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.
::[[User:Geyser|geyser]] 17:12, 21 October 2008 (CEST)
:::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.
:::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>
:::--[[User:Iritscen|Iritscen]] 18:01, 21 October 2008 (CEST)
::::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).
::::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.
:::::[[User:Geyser|geyser]] 19:19, 21 October 2008 (CEST)
::::::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...
::::::*"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.
::::::*"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.
:::::::*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]]
:::::::*I watched the trailer. Whatever it is doing it's not shadow mapping or any other "normal" shadow technology. If you want to see "normal" shadow watch the '98 movie (I suspect that one is CG, anybody knows?). It's very possible that those '99 "shadows" were using the dynamic pathfinding grid because that information is readily available. If they changed is either because they were ugly or because it turned out that they were more expensive that the decal we have currently.
:::::::PS: I'm going to do some cleanup here. If someone wants to preserve something scream now or go down in history to get it :).
:::::::[[User:Neo|Neo]]
----
==Large textures==
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)
Faces of Konoko: the 1st is the standard texture at 128x128, the 2nd is at 512x512 with some smoothing of the skin in Photoshop, the 3rd added the eyes from coool's texture.
http://edt.oni2.net/images/Konokoface.jpg
Did anyone notice how Konoko's lips look realistic? Maybe they used a photograph for it.

Revision as of 14:12, 10 November 2008

Retrieved from "https://wiki.oni2.net/w/index.php?title=User_talk:Neo&oldid=13249"