Engine level normal map support
Moderator: Moderators
Re: Engine level normal map support
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: Tell me something I don't know?
Re: Engine level normal map support
So why would it be bad to add native support since we cannot apply our own shaders to features?
Re: Engine level normal map support
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.Silentwings wrote:I'm confused by this
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
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: Engine level normal map support
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.
"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.
Re: Engine level normal map support
"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.
That's all i have to say about this.
Re: Engine level normal map support
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.
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.
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.
No doubt this won't win over popular opinion, but here are the downsides of *this* form of native support I can see:smoth wrote:So why would it be bad to add native support since we cannot apply our own shaders to features?
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.
If you forgo principle too long, you get Spring: quickfixes built on hacks on top of unplanned non-structural growth.Forboding Angel wrote:For the sake of principle?
Re: Engine level normal map support
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.Kloot wrote:No doubt this won't win over popular opinion, but here are the downsides of *this* form of native support I can see:smoth wrote:So why would it be bad to add native support since we cannot apply our own shaders to features?
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.
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.
Re: Engine level normal map support
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: 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
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: 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
Possible to crowdfund this?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.
Re: Engine level normal map support
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.
Other things i'd like to be shaderable: projectile models (including beams and unit piece projectiles), terrain, sprite particles.
Re: Engine level normal map support
The ball has been dropped a few times, yes. Issues with model formats/exporters/importers are a PITA to handle.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.
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)
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.
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.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.
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 wrote: Possible to crowdfund this?
Re: Engine level normal map support
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.Kloot wrote: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 wrote: Possible to crowdfund this?
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?
-
- Posts: 823
- Joined: 21 Oct 2008, 02:54
Re: Engine level normal map support
I do honestly do not mind doing this as a summer job.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: Engine level normal map support
Split map format discussion to here viewtopic.php?f=13&t=34082