I'll Write Something Relevant To The Thread For A Change
#2219 posted by dwere on 2016/08/22 19:19:32
Since the engine supports colored static lighting, are there any plans to add some colored dynamic lighting functionality? Right now all dynamic lights are white.
Textures
#2220 posted by Kinn on 2016/08/22 19:42:45
Have you seen the amount of colors used
It's a very manageable amount actually because the contrast of the textures is very low compared to the range of the colour ramps used - so the number of colours used from each ramp is low, and taken from the darker end of the ramp.
The light colours in the palette only get seen in the game once the lighting engine does its thing.
Trust me, I am currently creating my own quake texture wad by working directly with the palette colours and ramps, using a bespoke pixelling program I wrote for a company I worked at (which was inspired by pixel apps like DPaint and Pro Motion).
Here is a just one example of one of my textures. I don't pretend to be an amazing artist but the aim is to at least be consistent with the style and quality of quake's original textures. The number of colours used is really really low, simply a handful of colours from the lower end of about 3 of the ramps was used in this one, and this texture look literally minutes to bash out:
http://i.imgur.com/YN5DBmG.png
@dwere
#2221 posted by Baker on 2016/08/22 19:53:26
Do you know how DarkPlaces does colored dynamic lights?
(Hint: it's not pretty)
Damn
#2222 posted by killpixel on 2016/08/22 19:53:52
that looks great
#2223 posted by Baker on 2016/08/22 19:55:40
And what I mean, let's say you want a fireball to be orange lighting?
How do you tell DarkPlaces to make a fireball's dyanmic light orange?
(It's an uglier hack than a tour inside a hotdog factory)
Kinn
#2224 posted by dwere on 2016/08/22 20:26:47
Well, the stock textures are typically more smooth, and also occasionaly more "chaotic" in the sense that you can spot pixels that don't really belong color-wise. Some of these cases are clear mistakes that would've been hard to commit when picking colors manually.
In some cases you can clearly see that they blended two or more materials together. Quake even has some textures that are derived from Doom textures that were made of toy photos. And it's an efficient way of doing things. Although if you really made that texture in only a few minutes, I can only applaud your skill.
Baker
#2225 posted by dwere on 2016/08/22 20:35:17
I take it a cleaner solution doesn't exist?
Adding colors to old content retroactively isn't really necessary. I was thinking more along the lines of giving modders a way to assign colors in new mods. Like reading a certain entity field (if it is defined in QC), for example.
From My Experience
Dynamic colored lighting does not go well with static baked-in lighting at all. :(
From My Experience
Dynamic colored lighting does not go well with static baked-in lighting at all. :(
#2228 posted by Rick on 2016/08/22 20:46:07
I think color for the built-in dynamic lights would be a good addition. There are not that entities that move and give off light. Would it really be difficult to add?
(Lava balls
Magic bullets
Vore balls
Lightning
Rockets...)
What else?
Now, if somebody wanted moving light sourced from specific textures on doors, func_trains, and such, then I can see that being more of a problem.
Well -- First
#2229 posted by Baker on 2016/08/22 20:47:58
But a cleaner solution than what?
I asked if you knew how DarkPlaces does it. And clearly, you don't.
One would naturally conclude:
- You have so little interest in the feature that you never have used it for yourself in DarkPlaces.
#2230 posted by Rick on 2016/08/22 20:56:57
My only interest in colored dynamic light is from a mapping point of view. It just looks very weird to see the fireballs, rising from deep orange-red lit lava, giving off pure white light.
The others I mentioned would be nice, rockets etc., but beyond that I don't see it as all that necessary for Quake.
#2231 posted by dwere on 2016/08/22 20:59:15
But a cleaner solution than what?
Than a solution used in Darkplaces, which you clearly see as ugly. I trust your opinion.
You have so little interest in the feature that you never have used it for yourself in DarkPlaces.
I have little interest in Darkplaces.
But it's pretty clear from your reaction that this is an unwanted conversation for you.
Coloured Dlights
#2232 posted by Kinn on 2016/08/22 21:05:46
Like the rather icky r_noshadow_list stuff, could we just not whack a great big string into the config file that maps modelnames to colours?
It's ugly but we already have a precedent for doing things that way...
//
That particular texture was really quick because it's just quick splotchy strokes with a bit of shade and highlight. Doing precise metalwork shapes and stone carving decor and whatnot is a bit slower obviously.
@dwere
#2233 posted by Baker on 2016/08/22 21:07:34
Maybe if you educated yourself to understand what it is you think you want, you might see why it is unlikely to happen.
But instead, all your bring to the table is
- a lack of knowledge
- can't even be bothered to try it in DarkPlaces
- ignorance of not knowing what you are asking for
I think it is a bit rude to ask the Quakespasm guys for something you don't even know what it is, nor how it should work.
To Anybody Who Cares To Read This Rant.
On adding too much to the engine...
"Like reading a certain entity field (if it is defined in QC), for example. "
I'm pretty sure that is the kind of hackiness that baker was talking about. Modding in the engine is counter to what the philosophy of mods is to begin with.
Mods are programmed within the framework of what they're allowed to access / execute. Not only does it add bloat, but it also has the potential to break that mod for other engines. As soon as you bypass the vanilla framework you might as well just hard code the progs into the executable.
These features can be added, but where do you draw the line? I think the QS (and beyound that fitzquake) developers have done a great job at keeping engine bloat to a minimum.
I honestly think that quakespasm is not suited to visual enhancing features like darkplaces and co.
But you know what I did when I wanted IRC support in quakespasm? I learned some C and forked it myself. I wholeheartedly recommend that if you really want a feature added, then this is the way to go, not only do you learn a new skill, but you also get the feature that you want.
/rant over.
Directq And RMQ
I think had this and different colour coronas too, I'm sure they looked good because I stuck with those engines for a while
#2236 posted by dwere on 2016/08/22 21:26:44
Let me get this straight. Before I request a feature in an engine I'm interested in I need to:
- Be a programmer myself;
- Try the feature in an engine I'm not interested in;
- Understand that the feature is hopeless crap using my programmer knowledge;
- Never ask for it, because it's crap.
Did I miss anything?
#2237 posted by Kinn on 2016/08/22 21:29:59
Posting in this thread is like playing Dark Souls; at first you'll find it cruel and unforgiving, but after many days, weeks and months of practice you'll intricately understand the attack patterns of the various mobs that lurk here, and be able to parry and counter their posts effectively.
No
before you request a feature you need to:
- Prepare yourself for the possibility that the developers don't want to implement it.
- Not get salty when you don't get the answer you want.
Shamblernaut
#2239 posted by dwere on 2016/08/22 21:42:34
By not getting the answer I want you mean stumbling on an edgelord that I'm not even sure is one of the developers?
That's One Approach
Dwere
Baker is weird. But he knows what he's talking about when it comes to Quake engines.
Baker
Is certainly more articulate than Madfox, and provides far more polished content (ProQuake, Fitz V, etc) but god damn if their thought processes aren't equal.
#2243 posted by dwere on 2016/08/22 21:49:19
I kinda get that he knows things. That's why I said that I trust his opinion.
|