Textures are backwards?

[SpliFF]

I was having different issues with DDS textures than i was with PNG ones trying to setup the new model loader. Then I just ran across this little gem in another thread:

for dds you don't flip the texture. If I am understanding you right you are flipping teh texture prior to conversion.

Are you guys saying DDS textures are somehow ... backwards ... compared to PNG textures?

I'm just thinking the reason I was getting black models when loading the corraid_512.dds from Mr.D's core raider.

I'm thinking the issue might not have been my code at all but something odd about this whole texture flipping thing. I know it's related to DDS being a DirectX thing but what exactly should I be doing to my models / UV's or textures prior to applying these puppies?

If I'm trying to map a DDS texture, loaded via texturehandler->S3O onto an assimp model (which use OGL standard coords) do I need to take (or not take) certain steps prior to using glDrawElements to correctly map the UV's/bitangents? Is it actually the case that S3O is itself backwards and UpSpring is providing a hack to compensate? Is UpSpring backwards? Is Spring backwards?

If you need to flip UVs, in what directions?

[Peet]

I vaguely remember it being DevIL's fault that textures are upside down...except for DDSes. I could be wrong.

[Argh]

Are you guys saying DDS textures are somehow ... backwards ... compared to PNG textures?

No, PNG (and everything that isn't DDS) is backwards. Technically, it's upside down, just as all models are reversed left--right vs. most modelers.

what exactly should I be doing to my models / UV's or textures prior to applying these puppies?

Nothing. I guess it's possible the display list is being built without texcoords, but not real likely, since assimp's supposed to do that when it loads the model format, one would presume.

If I'm trying to map a DDS texture, loaded via texturehandler->S3O onto an assimp model (which use OGL standard coords) do I need to take (or not take) certain steps prior to using glDrawElements to correctly map the UV's/bitangents? Is it actually the case that S3O is itself backwards and UpSpring is providing a hack to compensate? Is UpSpring backwards? Is Spring backwards?

No, that's not possible. Even if the normals were flipped, you wouldn't see an all-black model. You'd see through most of it, depending on culling setup.

If it's fine with a PNG but borks with DDS... then, IIRC, there's more than one DDS handler, depending on whether we're loading a DDS for LuaUI (no mips), S3O (all mips, and make sure that assimp is savvy to that requirement, but it should be) or maps, so you may be grabbing the texture from the wrong function, or not passing it the correct param. IOW, you may not be grabbing a DDS with the number of mips it needs. Or assimp may be retarded, an only allow 5, 6, whatever mips, and a DDS with more isn't working right.

If neither is fine... well, have you done the basics, like set up a light? A totally-black, unshaded model is either missing a light or you have a screwed up the reference to the shaders (or you've plugged in the ARB shader without sending it all the data it requires, hehe) or otherwise it's not set up right- if you have a valid display list with texcoords (or even without, if you just assign a color). Try removing the textures and making sure it renders correctly with a light and plain white before going further.

[jK]

First DDS means DirectDrawSurface. Now DirectX has TopLeft origin for their screen coords, while OpenGL in contrast has a math-like BottomLeft origin. This is the same for the TexCoords. So it is DDS that flips the image.
The problem is now UpSpring that flips all TexCoords because it assumes DDS are used, but pngs don't need this flip ...
This is a very bad habit of UpSpring, because most dds compressor have an invert flag, or even Spring itself should flip all DDS itself before sending them to the GPU (I prefer the 2nd).

[SpliFF]

@Argh

Here we go again. DDS *IS* upside-down, even I know that. Nothing else you said answers the actual questions. You can't even answer them because I'm asking about internal structures you aren't familiar with. And the lights? Spring uses global and ambient lighting so you're miles off.

What I asked is what texturehandlerS3O, and by extension nv_dds, the bitmap handler and UpSpring is doing to the textures and UV coords at each step in the process. You don't know, so don't answer.

@jK

Thank you.

[Saktoth]

It is true though that flipped UV's should show flipped UV's (a garbled texture), not a black surface.

[SpliFF]

The black surface could also be a messed up specular, alpha or glow channel (no light being reflected, black light being emitted) but it's all besides the point. I'm not looking to fix the problem so much as understand the data structures because the entire assimp texturing pipeline is going to get a rewrite. So really, this isn't so much about the effects I'm seeing as it is about correctly loading and mapping the textures. If I'm still seeing these issues after the rewrite then i'll start a new thread to deal with the issues then.

All I wanted to know is what "format" UpSpring will deliver the data in and whether the DDS/DeviL or texture binding operations are doing any unusual transformations.

Maybe I was too hard on Argh because my post didn't spell that out but I was asking some pretty specific questions and his response was mostly speculation loosely disguised as information. If he didn't do it all the time I wouldn't get so upset. At least Peet had the coutesy to admit he was speculating, that simple act of modesty can save hours of operating on false assumptions and data.

I really only got as far as "Everything but DDS is backwards" and "Q: What do I need to do ..." A: "Nothing." before the rage kicked in.

[Argh]

If you have a black model, you are fucking up something pretty basic, guy. Quit condescending to people who write things that work.

[aegis]

everything you write works properly the first time?

[AF]

Argh your trips into OpenGL land have been glazed behind a pretty lua API. Here we're dealing with C++ and OpenGL, it's somewhat trickier than you'd think

[Argh]

I know that.

According to the API's manual, though, he probably needs to define an aiLight.

[SpliFF]

I know that.

According to the API's manual, though, he probably needs to define an aiLight.

And according to me that's a load of crap.

THE API doesn't do any lighting, it just exposes the lights in the scene. Assimp doesn't do ANY OpenGL OR texture loading, it just exposes processed model data in a single unified format instead of 20+ different formats (which is the whole point of my wanting s3o/3do pushed through it).

As for what is basic, and what is not, you're totally unqualified to answer that. As just pointed out P.O.P.s and your shaders are built on TOP of the actual system I'm trying to work with.

Anyway I take back my apology, this is the "Development" forum, not "Art and Modelling". If jK could figure out what I was asking then why didn't you? You've read enough of my other threads to realise I'm working on low-level code and I even specifically mentioned in one of those threads that I wasn't going to fix my current code but refactor the whole lot.

It may sound unfair to have a go at someone who is trying to help, but MISINFORMATION or speculation being put forward like it's hard facts is exactly the kind of thing that can turn development into a nightmare. EVERY TIME I make a mistake I have to RECOMPILE AND REINSTALL SPRING. If I have to do that 20 times because I'm working from flawed assumptions and outright lies then there goes 2-3 hours of time that could have spent on development or ACTUALLY RESEARCHING THE INFORMATION. Now multiply those hours by every person who reads your bullshit and tries to implement it and 2-3 hours becomes 20-30 hours or even days and weeks.

In short, posting misinformation and irrelevancies is actually LESS HELPFUL THAN POSTING NOTHING.

You wonder why jK and others rage dump every time you post on technical issues, well now you know. Do everyone a favour and stick to "Art and Modelling" and your own subforums where you actually have something to offer (even though it's apparent some people disagree on even that much). Even better, actually open up Spring's source code one day and take the time to learn it. Then you're not only helping yourself, but others as well.

In short, it's more important to be intelligent than sound intelligent when you're giving advice to others.

[FLOZi]

Reinstall spring after recompile? Why not just use the build directory?

[SpliFF]

Reinstall spring after recompile? Why not just use the build directory?

Because it usually doesn't pick up libraries and resources until 'make install' sets them up. If I pull a new Spring version then forget to make install then I'll get strange errors due to missing or incorrect resource; so I've set my build script to always do it - just to be on the safe side.

[Argh]

So, what was the problem then?

[Beherith]

RECOMPILE AND REINSTALL SPRING

Dont mean to barge in, since i dont know how this works on linux, but I find windows builds to be very simple in this matter.
Once the initial build is done (~10 minutes) each incremental build and launch afterwards takes less than 10 seconds.

[SpliFF]

RECOMPILE AND REINSTALL SPRING

Dont mean to barge in, since i dont know how this works on linux, but I find windows builds to be very simple in this matter.
Once the initial build is done (~10 minutes) each incremental build and launch afterwards takes less than 10 seconds.

I consider '10 seconds' to be highly unlikely. I have a pretty fast computer (3.0Ghz Dual-core) and it's more like 30secs -> 1 minute to rebuild and up to 1 minute to launch to game start then more time to perform tests. It's irrelevant anyway, this problem affects everyone hacking on Spring, people with older hardware more than others. I have a friend still hacking Spring on a P4 / GFMX4.

Misinformation is a serious problem. Your 10 seconds claim is probably just more misinformation, not to mention irrelevant and off-topic.

[AF]

You do know both of you are both right wrong iffy somewhere inbetween and wildly off all at the same time based on an infinite number of ways your systems could be configured software hardware wise as well as the details of where and how you built spring with what options.

e.g. 3Ghz Core i7 vs 3Ghz Dual core Athlon 64

Beherith may be running with 4 compile threads and an SSD

[SpliFF]

Which helps my friend how? I guarantee you he isn't using older hardware for fun.

What's the point of this derail? Are you saying it's ok for Argh to talk shit because I'm compiling wrong and my friend is poor? This thread is tapped out anyway, jK answered my questions in his first post.

[imbaczek]

It may be that VS incremental builds go waaaay faster than cmake/scons ones.