Engine level normal map support - Page 2

Engine level normal map support

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Engine level normal map support

Post by 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?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Engine level normal map support

Post by smoth »

So why would it be bad to add native support since we cannot apply our own shaders to features?
gajop
Moderator
Posts: 3044
Joined: 05 Aug 2009, 20:42

Re: Engine level normal map support

Post by gajop »

Silentwings wrote: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?
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14650
Joined: 17 Nov 2005, 02:43

Re: Engine level normal map support

Post by 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.
User avatar
Anarchid
Posts: 1383
Joined: 30 Nov 2008, 04:31

Re: Engine level normal map support

Post by 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
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Engine level normal map support

Post by 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.


smoth wrote: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.
Forboding Angel wrote: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.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Engine level normal map support

Post by smoth »

Kloot wrote:
smoth wrote: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.
Last edited by smoth on 19 Nov 2015, 06:37, edited 1 time in total.
gajop
Moderator
Posts: 3044
Joined: 05 Aug 2009, 20:42

Re: Engine level normal map support

Post by gajop »

Kloot wrote: 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.
Kloot wrote: 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).
Kloot wrote: 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?
User avatar
Anarchid
Posts: 1383
Joined: 30 Nov 2008, 04:31

Re: Engine level normal map support

Post by 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
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: Engine level normal map support

Post by Kloot »

smoth wrote: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.
smoth wrote: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.

smoth wrote: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.
gajop wrote: 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
Moderator
Posts: 3044
Joined: 05 Aug 2009, 20:42

Re: Engine level normal map support

Post by gajop »

Kloot wrote:
gajop wrote: 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
Posts: 820
Joined: 21 Oct 2008, 02:54

Re: Engine level normal map support

Post by Super Mario »

I do honestly do not mind doing this as a summer job.
User avatar
Silentwings
Moderator
Posts: 3686
Joined: 25 Oct 2008, 00:23

Re: Engine level normal map support

Post by Silentwings »

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

Return to “Engine”