I see your point, if a pwad has the same lump name somewhere but the pwad's material is visually and internally different, then the iwads name the and texture pack material name will be loaded instead, if "nopwad" flag wasn't there.
Actually, looking at the wiki again, there's no such thing as a "nopwad" there's only, ext, noiwad and pwad. http://dengine.net/dew/index.php?title=Reflection
So, really we can't have any flags lol.
~ well it shouldn't matter much if it's loaded with a pwad anyway because the texture pack its self is going to load as an addon anyway, the pwad flag in this case only has to do with a reflection, which is part of the texture that's being loaded anyway.
It seems as IF there was a nopwad flag, it should pertain to a texture as a whole, not just an effect stage of said texture.
Edit:
Okay, for now..
Flags = pwad ~ or nothing at all..
As the reflection stage has to do with the texture name (already loaded), in this case a hi-res texture pack which is enabled via check box, so the user has control over it. The flag only has control over the reflection stage.. so it doesn't matter much seems how the hi-res texture is already present..or isn't..
Might as well allow it to have a refection sence the custom texture "effect" is already there.
Yes Vermil I know the red is shinning a bit, I wanted that.
Now that I'v had a look at them, these shinymaps tend to look even more real than a basic non-animated brightmap, at least for the sort of lights that are on this texture. In most cases though I'd imagine it would look best as an effect for a silver highlight, as no doubt originally meant to be used for. Even though brightmaps need no sector light to do their job, shinymaps seem to look best in the light, at least around 170 sector brightness.
KuriKai, would you mind placing the above texture and script in the DHTP also?
SPCDOOR4 is looking real nice, good work Mr.Rocket At some point in the near future I plan to implement proper "brightmap" support, as hijacking the reflection for this means that naturally one can't also put a shine on there (which most metal materials should have).
With regard to the flags, yeah I was mistaken about nopwad/pwad - its indeed an enabler flag thus there should be no flags at all. Its been a while since I last looked at that code...
Thanks Danij,
I remember reading something about texture animation in the Wiki also. In the future when you get around to implementing brightmaps, how much trouble would it be to add a time table for smooth animations with brightmap lights? Essentially what a time table animation would do is control an R,G,B value. In most cases we wouldn't want lights to change color of course, but having this feature would allow us to change brightness as a whole to a single texture instead of using frames for animation. For example a red blinking or osculating brightmap light.
The idea is yes, from Idtech4 engine, here's an example:
The light_glow table shows how bright it starts, 0.7. However 1.0 being the brightest point and then gets darker back to 0.7 as the table loops this rgb value.
rgb light_glow[ time * .78 ] ~ rgb is a keyword stage in the material and light_glow is the global in this case. time * .78 is the table speed. ~ how fast the light blinks or glows in this case as the value is never below 0.7 so is never completely dark, acting as an osculating glow.
I think it would be a neat feature.
Although I'm sure the script would look totally different, but you get the idea.
----
Okay, thanks KuriKai, will be looking forward to it!
You can do blinking lights right now using animated light decorations. That way they'll be handled as light sources and so you'll get halos too. In your SPCDOOR4 case, I'd leave the red lights out of the brightmap and use decorations instead.
Before extending the material system further I first want to get the map surfaces rendered using shaders that we'll autogenerate from material definitions. Once that is achieved we'll be in a better position to determine what might be possible in future.
Yeah I know, you can do all sorts of light decorations.
I was just suggesting that this sort of thing as a possible brightmap texture feature though.
~ Something to consider anyway as it would give a lot better control on the side of detail in a brightmap texture (the animation of it in this case using a sort of time table).
~ I suppose the same sort of system that is used in light decorations could be adapted to a brightmap in DE though?
At that, I'm guessing the keyword brightmap could be added to a light decoration stage in the future?
Another idea is to have a sort of projection light where when a door is opened and the sector light is brighter in the other room, a projection light is spawned to match the given bright rooms sector light for a short time until the door is closed, ya I know that's asking a lot heh.
I don't agree that animating brightmaps by cycling a blending factor would give more control than the light decorations. If anything its more restrictive because you can't animate each source independently. Although I can see uses for it. Will definitely consider it.
Re: projection light
We plan to do something along those lines yes. The bias lighting model (light grid et al) already achieves something similar.
I don't agree that animating brightmaps by cycling a blending factor would give more control than the light decorations. If anything its more restrictive because you can't animate each source independently. Although I can see uses for it. Will definitely consider it.
Hi,
Well I wasn't saying it may be better or worse than any other current feature, I'm saying when the brightmaps are added in the future, a table/blending cycle animation for a brightmap texture would be a nice feature in its self, besides being a typical brightmap texture that would just light up. A table animation would at least allow for some control over the brightmap, without using any other current decoration. ~ not that other current light decorations etc. couldn't be "used with" this effect also.
In addition with other decorations.
Certainly it could produce some cool effects. There are some technical issues to consider here, though. In particular with regard to how lighting is composited.
The shinemap hack is quite an inefficient way to apply a brightmap because these result in an extra copy of the geometry and the shine is applied over the top of the actual map geometry. What I have in mind is a mechanism that renders brightmaps as part of the lighting pass so that their luminance can be sampled during postprocessing and then bloomed. This would avoid the current issues with bloom in that its working from the color intensities of the "diffuse" textures rather than the luminance of the material.
Of course not, I haven't made any textures for a DE for a long time.
@Danij, I see, and that's actually the way I look at it too, if something else is added to the shinymap decorations (but not to replace) for example. Of course hacking an improve is not the way to do it. A true way (is the right way) is how you see fit and I fully agree with your decision!
I am of course, simply throwing ideas out. You are the developer.
The shinymap is not the way to do it, but at least it doesn't look bad when there's no other way to do it. I'd much rather do such with a brightmap decoration instead also.
Well, I plan on making some more, but I doubt that I'll make the rest of them.
I'm currently taking a small brake from a mod called Arx - End of Sun.
But I want to keep my skills up so here I am. ~ at the moment.
Oh btw, BIGDOOR6 basically inherits the metal trim from MIDGRATE, so it would be pretty easy to create BIGDOOR6 using these materials, only thing is, the Lion head. There's a lion head switch in the build, so one of 2 things needs to be done, use the lion head and place it on BIGDOOR6, or create a new Lion head to replace them all..
Of course it would be easiest to just use the current Lion head, but to me the current lion head doesn't look like the one in DooM?
Not that the current Lion head isn't good quality, in fact it looks pretty good! ~ but to my eye, it just doesn't have that DooM look and feel, and that's what I'm shooting for.
there is no bigdoor6 in the pack. I removed the one that was in it because because it was really bad.
I like the overall look, but I think it needs some work on the bars (don't use black?). The bars need to be more twisted like these(http://thumbs.dreamstime.com/z/red-twis ... 696768.jpg) as you notice they are not a perfect vertical line.
Did you also compress the texture at all? looks like there has been some colour loss. You also seem to have used black for the shadows, I suggest using a dark grey.
@KuriKai, the bars are twisted, and I actually had an alpha channel setup where the curviness in the bars was present, however (that didn't look right in game), so I removed the curviness and recreated the bars with a solid line on the edges, have you looked at the texture in-game?
That's not black in the texture it's just really dark gray, the texture holds transparency properties.
If you would like to go to the trouble to edge enhance the bars so they appear more curved than they apparently are, feel free. ~ just remember the original texture doesn't have squiggly lines in its transparent background, so neither should this one!
The bars in the texture (should not) look anything like the off site image you posted!
Also, I'm aware there's no BIGDOOR6 in the pack, that's why I was talking about making one!
I have not seen the old BIGDOOR6 that use to be in the pack, again that's why I planned to make one. What did the old one look like? Who decided it was bad?
I don't know what you mean by "color loss"..
Does the texture need compressed? The 512x512 texture is only 250kb. But I could lower the color depth if that's what your getting at?
Most of his textures are in the DHTP (well I'm assuming, based off what Kuri Kai posted in that thread), except for the last few he made/was working on, which were BRICK12, MIDGRATE, BIGDOOR6, SW1/2LION and SW1/2SATYR.
what are the permissions on MIDGRATE? I agree with Kurikai that the bar edges should represent an actual twist although not to the extreme of his example. As they are, it looks to me like straight bars with painted on twist. Perhaps the originals did not have the pixels to show twisted edges.
@KuriKai, the bars are twisted, and I actually had an alpha channel setup where the curviness in the bars was present, however (that didn't look right in game), so I removed the curviness and recreated the bars with a solid line on the edges, have you looked at the texture in-game?
That's not black in the texture it's just really dark gray, the texture holds transparency properties.
you should try for a lighter grey, see how it looks. (bevels on the triangles and bolts really do look black
If you would like to go to the trouble to edge enhance the bars so they appear more curved than they apparently are, feel free. ~ just remember the original texture doesn't have squiggly lines in its transparent background, so neither should this one!
The bars in the texture (should not) look anything like the off site image you posted!
Of course it shouldn't look like the one i posted, it was an example of a twisted piece of metal to show you the edges aren't straight on metal when it is twisted
here is a better example
Also, I'm aware there's no BIGDOOR6 in the pack, that's why I was talking about making one!
I have not seen the old BIGDOOR6 that use to be in the pack, again that's why I planned to make one. What did the old one look like? Who decided it was bad?
I don't know what you mean by "color loss"..
Does the texture need compressed? The 512x512 texture is only 250kb. But I could lower the color depth if that's what your getting at?
well the darkish grey parts at the bottom just stop, there is no gradient, I can count 7 colours there.
also the bevels on the triangles at the top, are they smoothed or hard edged in your mind?
@KuriKai, the bars are twisted, and I actually had an alpha channel setup where the curviness in the bars was present, however (that didn't look right in game), so I removed the curviness and recreated the bars with a solid line on the edges, have you looked at the texture in-game?
That's not black in the texture it's just really dark gray, the texture holds transparency properties.
Well I know you're wanting to help, and I'm aware that the transparency is straight edged as stated previously. Again please read the above comment. do you see the part where I said: (that didn't look right in game) and then explained that I recreated the bars with a solid line on the edges.
Your second example that you're trying to show me is again not how it should look. The curve is too far apart in your off site image. I want you to look closely at the image you posted and tell me how many pixels do you think should be removed for transparency, maybe 3?
That said, there would be next to no difference.. in fact it would just make the bars look jittery.
As said, I have already done that and decided that a straight edge looks better. Again, in fact, the original is also straight edged.
License meaning what? Copyright stuff? Ah, I just care about getting a nice replacement. Copyright is overrated and holds us back as a species. It stifles the sharing of creative works and makes it so churning out new stuff takes longer. Being able to copy something and improve upon it is faster and more progressive than having to start from scratch every time. Humanity is an inefficient species in certain ways. Too much privatization mentality.
Edit: your bigdoor is not showing. It shows an x and says 'image'.
Comments
So we actually do need a flag:
Flags = nopwad
EDIT:
Actually, looking at the wiki again, there's no such thing as a "nopwad" there's only, ext, noiwad and pwad.
http://dengine.net/dew/index.php?title=Reflection
So, really we can't have any flags lol.
~ well it shouldn't matter much if it's loaded with a pwad anyway because the texture pack its self is going to load as an addon anyway, the pwad flag in this case only has to do with a reflection, which is part of the texture that's being loaded anyway.
It seems as IF there was a nopwad flag, it should pertain to a texture as a whole, not just an effect stage of said texture.
Edit:
Okay, for now..
Flags = pwad ~ or nothing at all..
As the reflection stage has to do with the texture name (already loaded), in this case a hi-res texture pack which is enabled via check box, so the user has control over it. The flag only has control over the reflection stage.. so it doesn't matter much seems how the hi-res texture is already present..or isn't..
Might as well allow it to have a refection sence the custom texture "effect" is already there.
No flags..
Cheers
Here's SPCD00R4 now with this effect:
Here's the brightmap, or in this case lightmap for it:
This is to be placed in the lightmaps/masks directory.
And here's the reflection script:
Yes Vermil I know the red is shinning a bit, I wanted that.
Now that I'v had a look at them, these shinymaps tend to look even more real than a basic non-animated brightmap, at least for the sort of lights that are on this texture. In most cases though I'd imagine it would look best as an effect for a silver highlight, as no doubt originally meant to be used for. Even though brightmaps need no sector light to do their job, shinymaps seem to look best in the light, at least around 170 sector brightness.
KuriKai, would you mind placing the above texture and script in the DHTP also?
Thanks
Will be in next pack
With regard to the flags, yeah I was mistaken about nopwad/pwad - its indeed an enabler flag thus there should be no flags at all. Its been a while since I last looked at that code...
Thanks Danij,
I remember reading something about texture animation in the Wiki also. In the future when you get around to implementing brightmaps, how much trouble would it be to add a time table for smooth animations with brightmap lights? Essentially what a time table animation would do is control an R,G,B value. In most cases we wouldn't want lights to change color of course, but having this feature would allow us to change brightness as a whole to a single texture instead of using frames for animation. For example a red blinking or osculating brightmap light.
The idea is yes, from Idtech4 engine, here's an example: The light_glow table shows how bright it starts, 0.7. However 1.0 being the brightest point and then gets darker back to 0.7 as the table loops this rgb value.
rgb light_glow[ time * .78 ] ~ rgb is a keyword stage in the material and light_glow is the global in this case. time * .78 is the table speed. ~ how fast the light blinks or glows in this case as the value is never below 0.7 so is never completely dark, acting as an osculating glow.
I think it would be a neat feature.
Although I'm sure the script would look totally different, but you get the idea.
----
Okay, thanks KuriKai, will be looking forward to it!
Thanks
Before extending the material system further I first want to get the map surfaces rendered using shaders that we'll autogenerate from material definitions. Once that is achieved we'll be in a better position to determine what might be possible in future.
Yeah I know, you can do all sorts of light decorations.
I was just suggesting that this sort of thing as a possible brightmap texture feature though.
~ Something to consider anyway as it would give a lot better control on the side of detail in a brightmap texture (the animation of it in this case using a sort of time table).
~ I suppose the same sort of system that is used in light decorations could be adapted to a brightmap in DE though?
At that, I'm guessing the keyword brightmap could be added to a light decoration stage in the future?
Another idea is to have a sort of projection light where when a door is opened and the sector light is brighter in the other room, a projection light is spawned to match the given bright rooms sector light for a short time until the door is closed, ya I know that's asking a lot heh.
Thanks
Re: projection light
We plan to do something along those lines yes. The bias lighting model (light grid et al) already achieves something similar.
Well I wasn't saying it may be better or worse than any other current feature, I'm saying when the brightmaps are added in the future, a table/blending cycle animation for a brightmap texture would be a nice feature in its self, besides being a typical brightmap texture that would just light up. A table animation would at least allow for some control over the brightmap, without using any other current decoration. ~ not that other current light decorations etc. couldn't be "used with" this effect also.
In addition with other decorations.
That would be sweet!
Cheers
The shinemap hack is quite an inefficient way to apply a brightmap because these result in an extra copy of the geometry and the shine is applied over the top of the actual map geometry. What I have in mind is a mechanism that renders brightmaps as part of the lighting pass so that their luminance can be sampled during postprocessing and then bloomed. This would avoid the current issues with bloom in that its working from the color intensities of the "diffuse" textures rather than the luminance of the material.
Of course not, I haven't made any textures for a DE for a long time.
@Danij, I see, and that's actually the way I look at it too, if something else is added to the shinymap decorations (but not to replace) for example. Of course hacking an improve is not the way to do it. A true way (is the right way) is how you see fit and I fully agree with your decision!
I am of course, simply throwing ideas out. You are the developer.
The shinymap is not the way to do it, but at least it doesn't look bad when there's no other way to do it. I'd much rather do such with a brightmap decoration instead also.
Cheers
I'm currently taking a small brake from a mod called Arx - End of Sun.
But I want to keep my skills up so here I am. ~ at the moment.
MIDGRATE is in the works..
Edit:
I give you MIDGRATE..
1024x1024:
http://home.comcast.net/~mrrocket/etc/midgrate.png
Thanks
Oh btw, BIGDOOR6 basically inherits the metal trim from MIDGRATE, so it would be pretty easy to create BIGDOOR6 using these materials, only thing is, the Lion head. There's a lion head switch in the build, so one of 2 things needs to be done, use the lion head and place it on BIGDOOR6, or create a new Lion head to replace them all..
Of course it would be easiest to just use the current Lion head, but to me the current lion head doesn't look like the one in DooM?
Not that the current Lion head isn't good quality, in fact it looks pretty good! ~ but to my eye, it just doesn't have that DooM look and feel, and that's what I'm shooting for.
Your thoughts?
Thanks
It should be possible to sculpt one that is more authentic.
Are you creating these with the possibility of creating normal maps from them at some point?
I like the overall look, but I think it needs some work on the bars (don't use black?). The bars need to be more twisted like these(http://thumbs.dreamstime.com/z/red-twis ... 696768.jpg) as you notice they are not a perfect vertical line.
Did you also compress the texture at all? looks like there has been some colour loss. You also seem to have used black for the shadows, I suggest using a dark grey.
@KuriKai, the bars are twisted, and I actually had an alpha channel setup where the curviness in the bars was present, however (that didn't look right in game), so I removed the curviness and recreated the bars with a solid line on the edges, have you looked at the texture in-game?
That's not black in the texture it's just really dark gray, the texture holds transparency properties.
If you would like to go to the trouble to edge enhance the bars so they appear more curved than they apparently are, feel free. ~ just remember the original texture doesn't have squiggly lines in its transparent background, so neither should this one!
The bars in the texture (should not) look anything like the off site image you posted!
Also, I'm aware there's no BIGDOOR6 in the pack, that's why I was talking about making one!
I have not seen the old BIGDOOR6 that use to be in the pack, again that's why I planned to make one. What did the old one look like? Who decided it was bad?
I don't know what you mean by "color loss"..
Does the texture need compressed? The 512x512 texture is only 250kb. But I could lower the color depth if that's what your getting at?
Do you plan on commenting on my actual question?
Not at the moment, it's however easy enough for me to generate a normalmap or heightmap, or specularmap if need be, or when the time comes.
Thanks
A lion texture: http://i.xomf.com/kpszn.png
I did most of my testing in map11 of Doom2, the texture shows its self a lot in that level.
Nice Lion head!, who made that?
I planned to draw a new lion head from scratch, that would be a nice reference!
Thanks
http://www.doomworld.com/vb/wads-mods/6 ... available/
Most of his textures are in the DHTP (well I'm assuming, based off what Kuri Kai posted in that thread), except for the last few he made/was working on, which were BRICK12, MIDGRATE, BIGDOOR6, SW1/2LION and SW1/2SATYR.
here is a better example
I decided it was bad, because it really was bad.
https://i.imgur.com/mm07QLs.png
well the darkish grey parts at the bottom just stop, there is no gradient, I can count 7 colours there.
also the bevels on the triangles at the top, are they smoothed or hard edged in your mind?
@KuriKai, the bars are twisted, and I actually had an alpha channel setup where the curviness in the bars was present, however (that didn't look right in game), so I removed the curviness and recreated the bars with a solid line on the edges, have you looked at the texture in-game?
That's not black in the texture it's just really dark gray, the texture holds transparency properties.
Well I know you're wanting to help, and I'm aware that the transparency is straight edged as stated previously. Again please read the above comment. do you see the part where I said: (that didn't look right in game) and then explained that I recreated the bars with a solid line on the edges.
Your second example that you're trying to show me is again not how it should look. The curve is too far apart in your off site image. I want you to look closely at the image you posted and tell me how many pixels do you think should be removed for transparency, maybe 3?
That said, there would be next to no difference.. in fact it would just make the bars look jittery.
As said, I have already done that and decided that a straight edge looks better. Again, in fact, the original is also straight edged.
I'm not going to repeat myself a 3rd time sorry..
Here's BIGDOOR6 which is also WIP, currently without the lion face.
Thanks
Edit: your bigdoor is not showing. It shows an x and says 'image'.