User talk:Neo: Difference between revisions
Jump to navigation
Jump to search
(re:hexagon, mostly) |
No edit summary |
||
Line 90: | Line 90: | ||
:::Hexagon "wrongness" - not sure what exactly you are talking about. Sure, it needs to be scaled up a bit (somewhere between x20 and x40), it needs to be rotated a bit and some textures have non power of 2 sizes. Appart from that "it just works". Currently I'm investigating some "falling through the floor" problems but it appears that the problem is in OniSplit and not in Hexagon. | :::Hexagon "wrongness" - not sure what exactly you are talking about. Sure, it needs to be scaled up a bit (somewhere between x20 and x40), it needs to be rotated a bit and some textures have non power of 2 sizes. Appart from that "it just works". Currently I'm investigating some "falling through the floor" problems but it appears that the problem is in OniSplit and not in Hexagon. | ||
:::[[User:Neo|Neo]] | :::[[User:Neo|Neo]] | ||
:Well, I'm OK with bgr32, actually (and I'd be even more OK if I could use bgra32 ^_^ ) - it's not like the levels we're importing so far have hundreds of detailed textures... So the only critical flaw with hexagon was non-power-of-two texture sizes? is that really a critical flaw (as in "blam"), or did 'Scen mess up somewhere else (he's the one who reported a blam after importing hexagon2.dae; I didn't try)? About the scale - it's funny, what units is the original in, then? I thought the original was in millimeters, and hexagon2.dae in decimeters, so that it should be scaled up by 1.5 or 2, not more... 30 you say? huh. --[[User:Geyser|geyser]] 02:00, 11 November 2008 (CET) | ::Well, I'm OK with bgr32, actually (and I'd be even more OK if I could use bgra32 ^_^ ) - it's not like the levels we're importing so far have hundreds of detailed textures... So the only critical flaw with hexagon was non-power-of-two texture sizes? is that really a critical flaw (as in "blam"), or did 'Scen mess up somewhere else (he's the one who reported a blam after importing hexagon2.dae; I didn't try)? About the scale - it's funny, what units is the original in, then? I thought the original was in millimeters, and hexagon2.dae in decimeters, so that it should be scaled up by 1.5 or 2, not more... 30 you say? huh. --[[User:Geyser|geyser]] 02:00, 11 November 2008 (CET) | ||
::Well, maybe you're OK with bgr32 (or bgra32) but Oni is not :). I don't know what OpenGL exact behavior is for non power of 2 sizes (XNA throws an exception) but some (or all) hardware does not support this for texture with mipmaps. | |||
::That "blam" may have been caused by other stuff in the level that was not cleaned up. The sample levels I mentioned above are completly empty (they don't even have a splashscreen :)). | |||
::I don't know what the correct scale is but 20-40 looks nice, my first impression was like: "wow, halo 2"... | |||
::[[User:Neo|Neo]] |
Revision as of 07:26, 11 November 2008
New OniSplit (beta) version: OniSplit v0.9.30
What's new:
- SNDD importer
- -WAV files (.wav, mono/stereo, 22.05KHz/44.1KHz, uncompressed(PCM)/compressed(MS-ADPCM)) produce SNDD files that are compatible with Oni PC retail.
- -AIFC files (.aif/.aifc/.afc, mono/stereo 22.05KHz, compressed(ima4)) produce SNDD files that are compatible with Oni Mac.
- Example
OniSplit -create out_dir test.aif OniSplit -create out_dir test.wav
- LOD support for creating TRBS files. This can be done by creating an xml file containing the following:
<?xml version="1.0" encoding="utf-8"?> <Oni Version="0.9.29.0"> <Instance id="0" type="TRBS"> <Elements> <Link>barabus_body_1.dae</Link> <Link>barabus_body_2.dae</Link> <Link>barabus_body_3.dae</Link> <Link>barabus_body_4.dae</Link> <Link>barabus_body_5.dae</Link> </Elements> </Instance> </Oni>
- and running the command (assuming the created xml file's name is barabus_body.xml):
OniSplit -create out_dir barabus_body.xml
- It's not strictly necessary to create 5 different geometries for each LOD. The following works just as well:
<?xml version="1.0" encoding="utf-8"?> <Oni Version="0.9.29.0"> <Instance id="0" type="TRBS"> <Elements> <Link>barabus_body_1.dae</Link> <Link>barabus_body_2.dae</Link> <Link>barabus_body_2.dae</Link> <Link>barabus_body_2.dae</Link> <Link>barabus_body_3.dae</Link> </Elements> </Instance> </Oni>
- An xml file can contain "links" to other xml/obj/dae files. For example you can have the following line in an ONWC xml file:
<Geometry>pistol.obj</Geometry>
- Assuming the file pistol.obj exists in the same directory an M3GM .oni file will be automatically created from it.
- Relative paths work just as well:
<Geometry>geometry/pistol.obj</Geometry>
- The -create:subt, -create:txmp and -create:m3gm are sort of obsolete. They still work but now you can simply use '-create' (or just 'create'):
OniSplit -create out_dir crate.dae OniSplit create out_dir -format:bgr555 -genmipmaps pic.tga OniSplit create out_dir subtitles.txt
- Work in progress: the AKEV importer now reads Collada materials so the resulting AKEV is textured.
- Sample levels:
- TestLevel1 -- This level should look like this in-game: Image 1 Image 2 Image 3
- TestLevel2
- A zip file contains the minimum needed to get a new level running in Oni. To "compile" a level extract it to a folder and run the following commands:
OniSplit -create out -genmipmaps -format:dxt1 *.xml OniSplit -import:nosep . Oni\GameDataFolder\level1_Final.dat
- (Of course, you need to change the output .dat file path to match your Oni installation path)
I did a quick update to 0.9.30 to fix a problem with relative paths handling.
- Iritscen - looks like you've overlooked the 0.9.30 fix when updating OniSplit. Neo - thanks a lot, I'll try to test the new features and put them to good use.
- Can someone tell me what was wrong with hexagon2.dae (unless it was just user error on the part of 'Scen?)? and what's up with using DXT1 for AKEV?
- geyser 01:34, 11 November 2008 (CET)
- DXT1 - well, you need to specify a texture format so you don't end up with bgr32.
- Hexagon "wrongness" - not sure what exactly you are talking about. Sure, it needs to be scaled up a bit (somewhere between x20 and x40), it needs to be rotated a bit and some textures have non power of 2 sizes. Appart from that "it just works". Currently I'm investigating some "falling through the floor" problems but it appears that the problem is in OniSplit and not in Hexagon.
- Neo
- Well, I'm OK with bgr32, actually (and I'd be even more OK if I could use bgra32 ^_^ ) - it's not like the levels we're importing so far have hundreds of detailed textures... So the only critical flaw with hexagon was non-power-of-two texture sizes? is that really a critical flaw (as in "blam"), or did 'Scen mess up somewhere else (he's the one who reported a blam after importing hexagon2.dae; I didn't try)? About the scale - it's funny, what units is the original in, then? I thought the original was in millimeters, and hexagon2.dae in decimeters, so that it should be scaled up by 1.5 or 2, not more... 30 you say? huh. --geyser 02:00, 11 November 2008 (CET)
- Well, maybe you're OK with bgr32 (or bgra32) but Oni is not :). I don't know what OpenGL exact behavior is for non power of 2 sizes (XNA throws an exception) but some (or all) hardware does not support this for texture with mipmaps.
- That "blam" may have been caused by other stuff in the level that was not cleaned up. The sample levels I mentioned above are completly empty (they don't even have a splashscreen :)).
- I don't know what the correct scale is but 20-40 looks nice, my first impression was like: "wow, halo 2"...
- geyser 01:34, 11 November 2008 (CET)