Engine level normal map support

[Kloot]

No; the comment you quoted was in reference to the parallel "If spring had bump generatinon as a graphics option" line of discussion.

smoth: Tell me something I don't know?

[smoth]

So why would it be bad to add native support since we cannot apply our own shaders to features?

[gajop]

I'm confused by this

Add me to that list. I would've thought that normal maps are general enough and don't belong to a specific form of art.
But maybe kloot suggests some more general purpose way of dealing with unit rendering? I could see uses for that but has there been any work towards it?

[Forboding Angel]

As I understand it (the way Kloot worded it is confusing), what kloot was saying was:

"If spring had bump generatinon as a graphics option"
This is no good because that belongs in the artist pipeline. Meaning that it should be up to the artist whether bumps get generated or not.

The way he states this is really awkward and as I understand it, a part of me sort of agrees, but another part of me says that if the engine can do it at essentially 0 cost as opposed to a shader which cannot do it without incurring a penalty... Why would the engine not do it? For the sake of principle? That seems like a really bad reason.

[Anarchid]

"You need to use this undocumented third-party scriptlet to get normals working on our engine"

That's all i have to say about this.

[Kloot]

That's the price you pay for continuing to stick outdated-inflexible-format models into your games.

OR

Maintaining backward compatibility has its price, deal with it.

OR

Complaining about having to use Lua to bypass engine limitations got old in 2007.


Take your pick.

So why would it be bad to add native support since we cannot apply our own shaders to features?

No doubt this won't win over popular opinion, but here are the downsides of *this* form of native support I can see:

1) it pushes back adoption of an industry-standard way of doing things (even further)
2) it continues reliance on S3O, which (being binary) is difficult to extend
3) it reduces the incentive to implement custom feature shader integration
4) it can not stand in for custom unit shaders when more than NM is desired

What you *want* is to put the current (tex1,tex2) model rendering in a legacy context and leave that the hell alone, and introduce a new one powerful enough to natively replace both it and the custom shaders for most cases. This is within the realm of possibility, though not as simple as a quickfix. Hacks by themselves might not be "bad", their effect on future development can be.

For the sake of principle?

If you forgo principle too long, you get Spring: quickfixes built on hacks on top of unplanned non-structural growth.

[smoth]

So why would it be bad to add native support since we cannot apply our own shaders to features?

No doubt this won't win over popular opinion, but here are the downsides of *this* form of native support I can see:

1) it pushes back adoption of an industry-standard way of doing things (even further)
2) it continues reliance on S3O, which (being binary) is difficult to extend
3) it reduces the incentive to implement custom feature shader integration
4) it can not stand in for custom unit shaders when more than NM is desired

What you *want* is to put the current (tex1,tex2) model rendering in a legacy context and leave that the hell alone, and introduce a new one powerful enough to natively replace both it and the custom shaders for most cases. This is within the realm of possibility, though not as simple as a quickfix. Hacks by themselves might not be "bad", their effect on future development can be.

Yeah but who is going to do that? I would love to see an update but right now, it has not happened. For years I was told that if someone actually used this crap that the one of the devs would take an active role. Now I have been using the shader code, no support beyond jk's initial code. I offered to entirely use assimp format collada in my new project, however, when I asked for support with the Yisup instead of Zisup, I was told, deal with it. My new project was entirely about giving the engine a project ready to move to modern standards but pretty much have been left hanging. I still am interested in it, if you guys add it, I will try my best to work with you, here I am wanting to do the grunt work from an artist perspective and while I may not be the best, I think I have proven my ability to just grind on and get a bunch of high quality content complete.

So if you are serious Kloot, I would happily work with you to produce test content, that is the whole reason I have my test game for my next RTS. However, it has been 2 years of me showing my work, showing that I am using it and mostly it collects dust. I am here, interested and willing to work with you guys! If you came to me and said, smoth, I need you to implement this model in x format doing y, if it is working towards my project goals, I would do it. SO..

1) what is the current standard? I am still a cowboy coder/artist. Can you better define it and I will make the adjustments.
2) y is up, give me this and I WILL move entirely to collada. That is my blocker. I do believe having y is up everywhere BUT the models is not consistent and it is confusing. Failing that I *CAN* go to z is up on all animations.
3) sup, been here, 2 years now playing with jk's shader code.
4) Killed() shaders turn off so any death animations(like modern games use) cannot work.

So I am here, an interested party with the time to do this stuff, but my time is running out, got married, when we have a kid, I will likely end up having much less time. As it stands, unity has been pulling hard because it does give me modern feature support. So are you serious? if you want to push us forward, I will learn what skills are needed provided you guys can give me support on the engine side.

[gajop]

1) it pushes back adoption of an industry-standard way of doing things (even further)
2) it continues reliance on S3O, which (being binary) is difficult to extend

What would 1) be? I'm all for industry-standards hence why I've asked to adapt this to collada as well (which seems behe has done). I definitely don't think we should be pushing for S3O in any shape or form.

3) it reduces the incentive to implement custom feature shader integration
4) it can not stand in for custom unit shaders when more than NM is desired

I think suggesting a better 1) may give us a hint how to solve for 3) and 4). I can definitely imagine more complicated unit shaders/textures (e.g. glow texture).

What you *want* is to put the current (tex1,tex2) model rendering in a legacy context and leave that the hell alone, and introduce a new one powerful enough to natively replace both it and the custom shaders for most cases. This is within the realm of possibility, though not as simple as a quickfix. Hacks by themselves might not be "bad", their effect on future development can be.

Possible to crowdfund this?

[Anarchid]

Count me in for "interested in crowdfunding advanced shader framework" camp.

Other things i'd like to be shaderable: projectile models (including beams and unit piece projectiles), terrain, sprite particles.

[Kloot]

Yeah but who is going to do that? I would love to see an update but right now, it has not happened. For years I was told that if someone actually used this crap that the one of the devs would take an active role. Now I have been using the shader code, no support beyond jk's initial code. I offered to entirely use assimp format collada in my new project, however, when I asked for support with the Yisup instead of Zisup, I was told, deal with it.

The ball has been dropped a few times, yes. Issues with model formats/exporters/importers are a PITA to handle.

1) what is the current standard? I am still a cowboy coder/artist. Can you better define it and I will make the adjustments.
2) y is up, give me this and I WILL move entirely to collada. That is my blocker. I do believe having y is up everywhere BUT the models is not consistent and it is confusing. Failing that I *CAN* go to z is up on all animations.
3) sup, been here, 2 years now playing with jk's shader code.
4) Killed() shaders turn off so any death animations(like modern games use) cannot work.

1) Just look at any of the major engines out there. The common materials for rendering a model include:

• diffuse (RGB)
• specular (RGB) + exponent (A)
• normal (RGB)
• height (A); used for parallax or relief mapping
• occlusion (A); used for modulating (ambient) lighting
• emission (RGB) + mask (A)
• reflection (RGB); used for modulating environment reflection
• detail diffuse (RGB) + mask (A)
• detail specular (RGB) + mask (A)
• detail normal (RGB) + mask (A)

Some of these can be packed together (and Spring also adds team-color and 1-bit transparency masks to the mix), but that gives you an impression. This was the industry norm circa 2009, and while the real state of the art (UE4, CE3, ...) has now moved to physically-based materials and better lighting models like Oren-Nayar, throw in a deferred renderer for the gamut of post-processing trickery and HDR dynamic lighting and you still achieve a nice step forward.

2) Not sure what we can do here. Your 3D editor needs to have the same idea about which axis points where as Spring does, and that rotations are executed in ZXY order. Blender unfortunately doesn't, so assimp has to internally perform a Z=up to Y=up conversion for Collada models.

3) I know, development has slowed down a bit. Custom feature shaders will be bumped in priority.

4) Has its roots in viewtopic.php?p=550595#p550595: on a semantic level nothing should come after UnitDestroyed, so fixing this requires breaking scripts.

As it stands, unity has been pulling hard because it does give me modern feature support. So are you serious? if you want to push us forward, I will learn what skills are needed provided you guys can give me support on the engine side.

Honestly, I don't know at this point. It is perhaps unfair to expect anyone else to do the engine rework, or small teams to produce such content for Spring. If the majority of game developers decide just having basic NM support suits their needs, it would not make much sense to push harder.

Possible to crowdfund this?

I want to say yes, and do think this project might be too huge to be tackled without funding. However I get the feeling the bounty initiative has created animosity (with accusations of greed being leveled), so whether it *should* be is another question.

[gajop]

Possible to crowdfund this?

I want to say yes, and do think this project might be too huge to be tackled without funding. However I get the feeling the bounty initiative has created animosity (with accusations of greed being leveled), so whether it *should* be is another question.

I think you shouldn't worry about that. I haven't heard these concerns from anyone that's actively contributing anything, so it doesn't matter anyway.
We *need* to solve some big issues with Spring if it is to have a future, and if paying is the way to go, so be it.

PS: Since it's highly related, what can be done to improve/extend the map rendering format? For starters I want to be able to have reflective, translucent maps (think glass) and much more. A bit of engine hacking got me the multi-bit translucency (http://i.imgur.com/vYNUZUD.jpg) but I hear it's not possible to compile such maps. What can be done to improve the map format?

[Super Mario]

I do honestly do not mind doing this as a summer job.

[Silentwings]

Split map format discussion to here viewtopic.php?f=13&t=34082