XML talk:TXMP: Difference between revisions

4,213 bytes added ,  20 February 2022
m
link fix
m (link fix)
 
(10 intermediate revisions by 3 users not shown)
Line 9: Line 9:
OniSplit does '''NOT''' require exactly power-of-two textures for importing via XML or <code>-create:txmp</code>. 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. <code>Note: I'm using "vanilla" OniSplit version 0.9.99.0. This note is important, because I have modified version of OniSplit from GeySer.</code> 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. --[[User:Mai X|Mai X]] ([[User talk:Mai X|talk]]) 20:36, 30 October 2021 (CEST)
OniSplit does '''NOT''' require exactly power-of-two textures for importing via XML or <code>-create:txmp</code>. 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. <code>Note: I'm using "vanilla" OniSplit version 0.9.99.0. This note is important, because I have modified version of OniSplit from GeySer.</code> 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. --[[User:Mai X|Mai X]] ([[User talk: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. --[[User:Iritscen|Iritscen]] ([[User talk:Iritscen|talk]]) 21:38, 30 October 2021 (CEST)
:I see, thanks for the info. I've adjusted the wording of the note on XML:TXMP. --[[User:Iritscen|Iritscen]] ([[User talk: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 <code>-create:level</code>) Tomorrow I will download and try with vanilla 0.9.99.0 currently on mod depot.--[[User:Paradox-01|Paradox-01]] ([[User talk:Paradox-01|talk]]) 01:44, 31 October 2021
[[image:AKEV_core_texture_512x499_imported_via_create_level_command_onisplit_0_99_9_2.jpg|thumb|Color-wise this was supposed to look like this... [[Image:Guido - Rendezvous.jpg|thumb]]]]
:::Same problem with 0.9.99.0. Actually two things happen.
:::# OniSplit converts 512x499 to 512x256 if -create:level is used.
:::# 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.--[[User:Paradox-01|paradox-01]] ([[User talk: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.<br>
P.S. Check my wiki page for some key features of my version of BFW.<br>
P.P.S. About your <code>-create:level</code> result I can say only one thing: <mark>It's S3!</mark> ^_^. Try to specify another pixel format via TXMP-XML. --[[User:Mai X|Mai X]] ([[User talk: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 <code>onisplit -create:level outputPath inputPath/lab.xml</code>
* http://mods.oni2.net/node/299
: 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 :)
:--[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 22:32, 31 October 2021 (CET)