Talk:New levels

          

Old talk

Mouth drops... you're now able to export and import level geometry??? --EdT 02:30, 2 August 2008 (CEST)

Who said anything about importing? Those are just XSI screenshots. --geyser 03:10, 2 August 2008 (CEST)

Exporting to COLLADA has been possible for a long time, though. --geyser 03:10, 2 August 2008 (CEST)

No ETA for importing yet, but it will happen... eventually. --geyser 03:10, 2 August 2008 (CEST)

Can you tell me the command to export the level geometry, I'll add it to the screenshot for AE Tools EdT 07:02, 2 August 2008 (CEST)

The command is simple, but you have to do a hack because of cross-level texture lookup. All the textures required by the level geometry need to be visible from the folder where the AKEV and AGDB are, so either in the same folder or in subfolders. As for the AGDB, you don't need one, but it makes the DAE files more modular and nicer to work with; you should be able use AGDB files from a PC installation. Because some of the textures are global to start with, the easy way is to globalize all the textures, and then temporarily move, say, AKEVpower.oni and AGDBpower.oni to GameDataFolder\level0_Final, and from that folder call onisplit with: -extract:dae power AKEVpower.oni This will create a GameDataFolder\level0_Final\power folder with a power.dae mesh and a bunch of TGA textures. Then you can put the AKEV and AGDB back where they belong, and also move the "power" folder wherever you like. --geyser 12:28, 2 August 2008 (CEST)

Thanks for the info, Blender is not able to import the.dae correctly, it loses the texture info. If you have time, can you upload a couple of AGDB files perhaps for airport or TCTF headquarters. I can test if it make a difference. Note: I guess you need to update the info for AGDB on the wiki, its not useless after all. Thanks EdT 18:06, 2 August 2008 (CEST)

HERE are the AGDB, but I can't see how it'll help Blender, except maybe it has trouble with handling huge objects. Maybe tell us more about how it "loses the texture info". As for the AGDB documentation, it is not used by Oni's engine. The fact that it's useful to OniSplit when exporting is an anecdote ^_^ --geyser 18:18, 2 August 2008 (CEST)

Thank you for the files, here's a comparison, ignore the image size difference. I say AGDB is quite useful for OniSplit.

With AGDB (.dae size 8.3MB)

Without AGDB (.dae 3.3MB)

EdT 22:13, 2 August 2008 (CEST)

geyser: I thought you were busy on non-Oni matters :-)

You mentioned about importing new level geometry. Does this mean we can take an existing level geometry modify it and then import it back to Oni. I don't mean major modifications, but maybe adding more cars to the TCTF parking garage or adding explosive barrels (That's just a crazy idea floating on OCF at the moment, Loser actually got one working except the barrel still remains after the explosion http://loser.oni2.net/Videos/Sorta_exploding_barrel.wmv ) EdT 02:10, 10 September 2008 (CEST)

geyser: Pathfinding works great in the arena. I went up the stairs, the AI followed. I jumped down and the AI came down the stairs. We need an OTA for this level :-)

EdT 14:21, 8 November 2010 (UTC)

Is that an enthusiast speaking, or a beta tester? You should have tried going under the stairs, or jumping down backwards, while looking at the AI. In the current version I've fixed the stairs, but the BNV height still needs to be increased. Until then, the AI will become stuck whenever you hold-jump-flip as Konoko, hold-jump as a ninja, or shapeshift to Mutant Muro (not to mention the vanishing ninja dodge moves). geyser 14:21, 8 November 2010 (UTC)

As for OTA, I'm really not sure. At this point it needs a new core logic, and ideally it should be interfaced with Flatline (maybe more like a Flatline script than an Oni script), but you Mac folks will probably want a standalone OTA. Just do it yourselves, then. As for me, I intend to use the arena for a demonstration of advanced lighting techniques (radiosity and/or lightmapping), and then I shall move on to other things. geyser 14:40, 8 November 2010 (UTC)

It was the enthusiast in me that was commenting :-) I'll modify an OTA script to work in the arena, it should be fun. Now to see the advanced lighting techniques, will that require the modified Oni engine? EdT

Not sure what you mean by "modified" Oni engine. Neo's Motoko? In the original engine, vertex shading is glitchy, and "my" lightmaps sorta work but not quite. AFAIK, Neo's Motoko fixes vertex shading, but does not make "my" lightmaps work any better. So I guess the answer is: wait and see. I'm not sure how long though. geyser 00:25, 9 November 2010 (UTC)

Regarding the lightmaps, no flickering at 1024x768, but there is dithering. EdT

I'll need an explanation of what you mean by "dithering", ideally a screenshot. There's not supposed to be any dithering for either flavor. The 4-bit version will have wikipedia:posterization a.k.a. banding. Is that what you mean? In any case, try and get the 8-bit version to work (you must byte-swap the BGRA channels to ARGB, if I remember correctly). geyser 22:05, 14 November 2010 (UTC)

Sorry, the correct term was banding :-) I will try swapping the channels, next time I have some free time. EdT

No hurry for the 8-bit version, the only difference about it should be the lack of banding. Apparently we've established that the Z-fighting (flickering) is gone. Now we probably need to have OniSplit consolidate the mesh automatically upon import (e.g., snap vertex coordinates to the nearest sixteenth-of-an-integer, or something like that), so that the polygons and their lightmapped duplicates coincide exactly. We also need to disable collision for the lightmapped mesh. I will try to consolidate the arena manually ASAP, and upload a flawless lightmapped version for you guys to use in videos etc. Tutorials will come later. geyser 01:46, 15 November 2010 (UTC)

8-bit Lightmap Screenshot:

4-bit Lightmap Screenshot:

Both are at 1024x768

Note: here's the channel swapping to make 8 bit work on the Mac:

R to A

G to R

B to G

A to B

EdT

Thanks for testing all this. We shall need a confirmation of those channel-swapping rules. Ideally, you should download THIS, load it in Oni as-is (level 5) and take a clear screenshot of the central "pillar". geyser 21:07, 17 November 2010 (UTC)

Here it is:

Note: The above channel swapping applies to the PPC version of Oni. We have tested RGBA8888 textures in the Intel Oni build and it behaves like the PC version.

Your 8-bit lightmap level with the PC version of Konoko HD without any modifications.

EdT

Thanks. Just two more things about these "type-7 textures" (I used to call them BGRA8888 and OniSplit calls them -format:bgra32, but you call them RGBA8888, which is apparently what they really are...):

1. Apparently the Daodan, Neo's Motoko, and Intel Oni all read the four bytes of the pixel data as RGBA (the PPC version of Oni byte-swaps the data and effectively reads it as ABGR). However, OniSplit stores it (incorrectly) as BGRA, so the textures aren't WYSIWIG even on PC.
2. Can you see a difference between THIS and THIS for PPC Oni? (and for Intel Oni?) It's the "little-Endian" flag of TXMP; if it works, it will be easier for OniSplit to accommodate the PPC version (once it fixes the BGRA order to RGBA). --geyser 22:39, 17 November 2010 (UTC)

Oh, and another thing. What is the proportion of Mac folks (I mean Oni fans, of course) that do not have an Intel Mac at this point? If it's negligible, maybe we should stop bothering with supporting the PPC version at all? By "we" I mean not only Neo, but also myself, because I'd be the one supplying lightmaps, and obviously I don't want you to swap the channels manually for every texture of every release. But if all the key folks have Intel Macs, that means I can relax a bit, right? --geyser 22:59, 17 November 2010 (UTC)

1. I will test this soon, after touching base with EdT.
2. Very few Mac users do not have Intel machines, and the ones that don't are planning to buy them. We still have to support PPC because there really isn't any Intel build yet (beyond a tiny tester group), but I think the days of the good ol' RISC architecture are numbered. As soon as the Intel build is released, we can probably drop support for PPC without any public outcry occurring. --Iritscen 23:36, 17 November 2010 (UTC)

Here's the comparison screenshots:

---

@Ed:

Thanks. It's good to see that the little-Endian flag (ON in "BGRA", OFF in "BGRAbis") has an effect on both Mac versions; like I said before, this will make the PPC version much easier to support OniSplit-side (upon -import).

1. Intel Oni behaves the same way as Daodan and Neo's Motoko, so there's nothing to fix there. The only things that need fixing, in two different ways, are the PPC engine (force or un-force an extra byte-swap for this texture type) and OniSplit (make it store the texture as RGBA instead of BGRA).
2. Good. Then, as far as lightmaps are concerned, I'll just forget about PPC, and let you handle the public outcry if any.

geyser 01:15, 18 November 2010 (UTC)