XML talk:TXMP: Difference between revisions

From OniGalore
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 21: Line 21:
Let me explain the situation in more detail so we all are "on the same page".
Let me explain the situation in more detail so we all are "on the same page".


This is a trimmed example on an level import with <code>onisplit -create:level outputPath inputPath/lab.xml</code>
This is a trimmed example (code) of a level import with <code>onisplit -create:level outputPath inputPath/lab.xml</code>
* http://mods.oni2.net/node/299
* http://mods.oni2.net/node/299
: lab.xml
: lab.xml

Revision as of 21:38, 31 October 2021

Unknown0010 flag

I Think that it was used by original Importer. Quote from SRC: "M3cTextureFlags_PixelType = (1 << 4), // only used when importing"
--Mai X (talk) 22:08, 17 September 2021 (CEST)

Power of 2

If I remember correctly power of 2 tex are required for onisplit Importing Levels. In some scenarios. Shrugs. --Paradox-01 (talk) 00:41, 13 October 2021

Neo thought that it was a bad idea to use non-power-of-two textures. See User_talk:Neo/Archive5. So he might have required them in OniSplit for importing levels (haven't tested this). Considering his expertise in the Motoko code, if he says that some hardware and software had trouble with non-p.o.t. textures then I'll have to believe him. I've added a cautionary note to the page about this. --Iritscen (talk) 14:38, 23 October 2021 (CEST)

OniSplit does NOT require exactly power-of-two textures for importing via XML or -create:txmp. I've tested it during testing 8192x8192 lightmaps. The table of power-of-two textures in OniSplit is only up to 1024. So, my 8192x8192 textures are not power-of-two (according to OniSplit's warnings), but they are working just fine. Note: I'm using "vanilla" OniSplit version 0.9.99.0. This note is important, because I have modified version of OniSplit from GeySer. All proofs will be soon in my Engine-Demo video (featuring "smart" animated textures, hi-poly physics, lightmaps, holographic characters, etc.). Check my wiki page. --Mai X (talk) 20:36, 30 October 2021 (CEST)

I see, thanks for the info. I've adjusted the wording of the note on XML:TXMP. --Iritscen (talk) 21:38, 30 October 2021 (CEST)
Mai X, you mean you have a vanilla Onisplit and an modified oni.exe from geyser?
I checked back on 0.9.95.0. "Non-standard" (like 512x499) tex get imported and loaded but ingame some pixels have wrong colors: they are green. (Imported with -create:level) Tomorrow I will download and try with vanilla 0.9.99.0 currently on mod depot.--Paradox-01 (talk) 01:44, 31 October 2021
Color-wise this was supposed to look like this...
Same problem with 0.9.99.0. Actually two things happen.
  1. OniSplit converts 512x499 to 512x256 if -create:level is used.
  2. They colors get distorted. While the change in dimension seems intended, the later seem to be a bug. When you convert the TXMP back to jpg it has wrong colors. So this is not an engine problem.--paradox-01 (talk) 13:52, 31 October 2021 (CET)

Stop! Under "modified Oni.exe" I mean my own version of the engine! I'll share all my SRC's with GeySer (when I'll finish the development process). Some problems with colours can exist. I'll continue my tests.
P.S. Check my wiki page for some key features of my version of BFW.
P.P.S. About your -create:level result I can say only one thing: It's S3! ^_^. Try to specify another pixel format via TXMP-XML. --Mai X (talk) 20:32, 31 October 2021 (CET)

Let me explain the situation in more detail so we all are "on the same page".

This is a trimmed example (code) of a level import with onisplit -create:level outputPath inputPath/lab.xml

lab.xml
<?xml version="1.0" encoding="utf-8" ?>
<Oni>
   <Level SharedPath="../shared">
       <Environment>
           <Model>
               <Import Path="env/lab_env.dae"/>
               <Import Path="env/lab_motorcycle.dae">
                   <Node Id="motorcycle">
                       <ScriptId>9</ScriptId>
                       <GunkFlags>NoCollision</GunkFlags>
                   </Node>
               </Import>
               <Import Path="env/lab_elevator.dae">
                   <Node Id="AnimElevator">
                       <ScriptId>540</ScriptId>
                   </Node>
               </Import>
               <Import Path="env/lab_bomber_window.dae"/>
           </Model>
           <Rooms>
               <Import Path="env/lab_bnv.dae"/>
           </Rooms>
           <Textures>
               <Texture Name="TCDOORGLASS">
                   <Format>bgra4444</Format>
               </Texture>
               <Texture Name="GOO">
                   <Format>bgra4444</Format>
                   <GunkFlags>NoCollision</GunkFlags>
                   <Image>env/images/GOO.tga</Image>
               </Texture>
           </Textures>
       </Environment>
       [...]

As you can see it is possible to declare individual texture properties in <Textures>.

But the usual case is to not use it for reasons of comfort. When you have a level with 2000 JPG / RGB standard textures you don't want to declare that many "exceptions" or even write individual TXMP*.xml files. Usually you simply build your level in XSI or blender and OniSplit will convert the referenced JPGs in the DAE file (here "lab_env.dae") to standard TXMPs. This works perfectly fine as long as you have power-of-two textures.

So all I'm trying to say is that -create:level will produce correct TXMP if power-of-two is used. But -create:level will produce corrupt TXMP if non-p.o.t is used.

You should check the source code of OniSplit that handles the automatic scaling of non-p.o.t textures when -create:level is used.

-create:level is such a great feature for the modding community and should be made bug-free. Also: only tga, jpg, png can be used for the AKEV core geometry and -create:level combination.

I hope we are on the same page now :)

--paradox-01 (talk) 22:32, 31 October 2021 (CET)