problem with feature freeze

[jK]

I finished the refactor of the model handling.
It merges a lot of 3do and s3o code and makes writting of new parsers much easier. But like you can imagine it affects a lot of synced and unsynced code w/o giving the user (in the current form) many advantages.
So do I have to make a branch or is 78 delayed, so I can commit and perhaps see if I get GLSL shaders running till the next release?

PS: a small list what the patch does:

• 3do and s3o are now IModelParser interfaces (just need Load() and Draw())
• 3dmodelparser does now all the other stuff (creation of LocalModel instances, model cache, model parser managment)
• no more S3DO & SS3O, they are now derivatives of S3DModel and S3DModelPiece, so there are just 4 classes/structures: S3DModel & S3DModelPiece and their local instances LocalModel & LocalModelPiece.
• merged most parts of the 3do and s3o rendering, to do so it will create now a tex2 even for 3do and will use the alpha in the first tex for the teamcolor (so it won't create duplicates of the 3do teamtexs in the atlas -> more space)
• refactored piece settings (pos,rot,visible) out of COBInstance into LocalModelPiece, so COB is now optional and not needed for rendering anymore, also if lua gets the interface it will be able to animate all pieces and not only those which are known by the cob. It will make also some OpenGL stuff easier, so you could update the piece matrices on demand instead of on runtime, etc.

PPS: I post here because I don't have post-rights in the svn subforum.

[lurker]

[*]merged most parts of the 3do and s3o rendering, to do so it will create now a tex2 even for 3do and will use the alpha in the first tex for the teamcolor (so it won't create duplicates of the 3do teamtexs in the atlas -> more space)

Is this just a tiny texture with nothing in it, or can I add reflectivity and glow to a collection of 3do models?

If actually using this texture is possible, is it the same size or can the faces have different coordinates in it, letting it be smaller?

PS: You should have asked tobi just in case it ever comes in handy like I did.

[jK]

There is already the reflectivity in it (tga alpha channel), so it is in the same size and uses the same texcoords as atlas tex1. So technically it would be possible to add self-illum, but then you need a 2nd 3do texture (perhaps with a special extension), I don't think it worth the affort.

[lurker]

Do many ta textures have that? Not a lot looks very reflective that I recall.
Why again did no one commit the split of reflection and specularity?

[Kloot]

Because ~50% of the mod devs (and jK) were against it.

[lurker]

And it's how hard to copy the texture channel based on a modoption flag? Sure, some people were against the specific implementation, but so what? Fine, I'll go off into foreign parts of spring and code it myself. Or is it easier to make it so mods can replace the shaders? (If they already can then that earlier thread really missed the mark.)

[jcnossen]

Wow that is really good news. This was a really big problem for any progress towards skeletal animation formats.

[Kloot]

And it's how hard to copy the texture channel based on a modoption flag?

Leaving out the details of the copying, let's review this idea:

• When the flag is set to true (S and R are used), we have that
  1. For old S3O's the (S&R) data in S is copied to R (so no visual change)
  2. For new S3O's their custom R data is overwritten by the data in S
  
  When the flag is set to false (ie. only S is used), we have that
  1. Old S3O's render as they do currently
  2. New S3O's render as if they don't have their custom R

Go implement it, boy genius.

(TLDR: there's no way to cleanly preserve backward-compatibility)

[thesleepless]

s3os have a version identifier, can just switch it based off that?
new s3os can be version = 2

[jK]

This would need an abstracted model rendering system. Lua already has such one, but it would have first to be made useable by the engine, too.
This answeres also the question of lurker ... it has be done with Lua.
(I already have such a gadget, but because of incompability with the LUPS cloak fx, it isn't used yet)

[lurker]

Kloot: What.

I don't think we're talking about the same flag. With my proposal, both S and R are used either way, like this:

If the flag is false, the texture gets copied, so that
1. Old S3Os render as they do currently
2. New S3Os render as if they don't have their custom R (script to update the textures and set the flag, modders)

If the flag is true then nothing is copied, so that
1. Old S3Os only have S, not the R they should (script to update the textures, modders)
2. New S3Os render beautifully



I think your flag does two things at once, or something. Both copying the texture and changing what channels the shader uses. Very confusing.

[Auswaschbar]

Does it work? Will it fix the rendeing issues with various mods (imperator in THIS)?

[jK]

The imperator renders correctly, but I just heard about that issue once by KDR and I don't know what he did at the end to solve it (I gave him some tips). So I don't what is causing it in 77b5 nor what fixed it (does it work in normal svn build?).

[lurker]

KDR said something about having to render it in lua. IIRC the issue was spring not rendering when it was partially offscreen. (center?)

[FLOZi]

KDR said something about having to render it in lua. IIRC the issue was spring not rendering when it was partially offscreen. (center?)

There's a similar issue with S44 ships. I can give you the S44 SVN info if you want ot check it out.

[Auswaschbar]

The imperator renders correctly

It doesn't renders for me with svn trunk. This qualifies as bugfix then, feel free to commit.

[zerver]

Please note that the delayed initialization of models via FixLocalModel() is intentional and was introduced to keep all OpenGL calls inside Draw().

Don't change this - the multithreaded build will fail.

[jK]

Okay, I found the problem.
It is the same I have/had with CA's icongen, it is caused by one of zerver's GML patches. It breaks any lua unit rendering as long as the engine didn't load the model itself already.
I fixed this for non-GML builds in my patch.
To fix it even for multithreading here is my solution (I can't do it myself because I don't have a multicore nor any clue how GML works):

AFAIK there are 3 different types of threads atm: one simulation thread, multiple render helper threads (unit/terrain rendering) and one rendering thread. Only the third has access to the OpenGL context and the render helper threads have indirect access to it via wrappers. So any rendering in the sim thread is impossible. So instead of disallowing it (that's the policy zerver followed) you should create an offscreen render context in the sim thread(s?) and link it with the SDL OpenGL context via sharelist. Then you could create DisplayLists, use RenderToTexture, preload textures even in the sim threads.

Yeah, I know it is easier said than done. So each OS use their own functions/interface (WGL,GLX & AGL). But this is the only way to fix this type of issue for any future builds of spring, so no way will follow around this solution.

PS: I know the problem here is a bit different (the specific lua code runs already in a render thread, but it still delays the displaylist creation because it can't check for the current thread type), but removing all the code to make it sim thread safe will solve the issue and is much cleaner.

[KDR_11k]

KDR said something about having to render it in lua. IIRC the issue was spring not rendering when it was partially offscreen. (center?)

Yeah, the thing has a pretty small hitsphere compared to its total size and uses Lua to get rendered when any of its hardpoints are in view. The rendering issue is that the voidwater threw shadows on the deck of the thing.

[zerver]

For the sake of simplicity, I'd be happy if the problem could be worked around by rewriting some LUA code in the affected mods.