rd-rend2 (old thread)

[DT.]

Wouldn't take much to tweak the underwater color in cgame, in your own fork of OpenJK. It's from what I remember, an RGB setting that will take seconds to edit.

[Archangel35757]

Wouldn't take much to tweak the underwater color in cgame, in your own fork of OpenJK. It's from what I remember, an RGB setting that will take seconds to edit.

But just changing that one RGB value in C game is just another hardcoded change... what I'm suggesting will take a little bit more code so that it automatically samples a color that complements the water brush itself. A brown muddy river is different than the clear waters of the Bahamas.

[Xycaleth]

Taking out the tint from cgame will mean any mods run with the vanilla renderer don't see any blue tint :/ And the vast majority of mods don't use OpenJK as a base, and are no longer being maintained/updated.

[Archangel35757]

Taking out the tint from cgame will mean any mods run with the vanilla renderer don't see any blue tint :/ And the vast majority of mods don't use OpenJK as a base, and are no longer being maintained/updated.

I'm sure a method can be coded to have the original color be a default value... based on some Boolean logic check

[eezstreet]

I'm sure a method can be coded to have the original color be a default value... based on some Boolean logic check

How would you propose the cgame code be able to determine that? The cgame has no concept of what renderer is currently loaded. The best you could do is check the cl_renderer cvar and compare the string value, but that's yet another hardcoded check that's really ugly.

[Archangel35757]

How would you propose the cgame code be able to determine that? The cgame has no concept of what renderer is currently loaded. The best you could do is check the cl_renderer cvar and compare the string value, but that's yet another hardcoded check that's really ugly.

I thought such a change would be independent of the renderer as you guys are saying it is a simple RGB color overlay with some large percentage of transparency, no? So either rend2 or the Vanilla renderer render this RGB color now, yeah?

 

All I'm saying is to modify the cgame code so that it is not single hard-coded value... but rather gets it's RGB value from the color of the water brush itself.

[gerbilOFdoom]

I thought such a change would be independent of the renderer as you guys are saying it is a simple RGB color overlay with some large percentage of transparency, no? So either rend2 or the Vanilla renderer render this RGB color now, yeah?

 

All I'm saying is to modify the cgame code so that it is not single hard-coded value... but rather gets it's RGB value from the color of the water brush itself.

I think what Archangel is trying to say is that the water filter should be put in place by rend2 such as that it only applies when it won't interfere with cgame drawing its overlay. So, if cgame is not drawing an overlay then rend2 takes over completely for a nice fancy water effect. If cgame is drawing then rend2 does, at most, some sort of intermediate compatibility effect or no effect at all. This is something that could be coordinated by a variable. cg_? I think. Or r_?. I'm not sure, haven't been doing much of JKA stuffs in awhile. 

[Circa]

Some of this is leaning towards semantics. 

 

What Archangel is wanting is a solution of some sort. I don't think other mods really matter at this point. I can't think of any that use OpenJK anyway. If people want rend2, they'll figure out a way to implement it, which in turn would allow them to implement this blue overlay fix, no?

 

What gerbil said above makes sense as well, though not sure if it's possible.

[Archangel35757]

I think what Archangel is trying to say is that the water filter should be put in place by rend2 such as that it only applies when it won't interfere with cgame drawing its overlay. So, if cgame is not drawing an overlay then rend2 takes over completely for a nice fancy water effect. If cgame is drawing then rend2 does, at most, some sort of intermediate compatibility effect or no effect at all. This is something that could be coordinated by a variable. cg_? I think. Or r_?. I'm not sure, haven't been doing much of JKA stuffs in awhile.

 

Someone please clarify my confusion... so this water filter overlay color is hard-coded in cgame. The vanilla renderer or rend2 simply render this fixed color based on whatever parameter stores this hard-coded RGB value, yes?

 

So I am suggesting to modify the cgame code so that this water filter RGB color is a modifiable value based on a color that compliments the water brush itself... e.g. muddy river, green pond water, clear Bahamas, blue ocean, etc. (Do water brushes themselves have some sort of color value? Perhaps the caulk_water Shader can have a property for this overlay RGB color-- then it can be a unique value for each water brush area)

[gerbilOFdoom]

Someone please clarify my confusion... so this water filter overlay color is hard-coded in cgame. The vanilla renderer or rend2 simply render this fixed color based on whatever parameter stores this hard-coded RGB value, yes?

 

So I am suggesting to modify the cgame code so that this water filter RGB color is a modifiable value based on a color that compliments the water brush itself... e.g. muddy river, green pond water, clear Bahamas, blue ocean, etc. (Do water brushes themselves have some sort of color value?)

The cgame code can be modified, yes, but cgame isn't part of the renderer. Any mod that has a client-side will modify the cgame so any change made by openjk to cgame will be lost unless the mod author uses OpenJK's cgame as the base. As of this moment, most cgame modifications don't use OpenJK so coordinating the change would be really difficult.

 

The important part of OpenJK is that you can use one part or all parts without breaking anything. Any change made that would require coordination between cgame and the renderer need to work independently of each other as well.

 

Now, as for modifying the  cgame code for different RGB values: cgame is just passing alone 'what' to render to the renderer. If it passes a box with a blue shader attached, a blue box will render. If it passes water with a green shader attached, icky green water will render. Cgame is not designed to do any graphics work so having cgame decide what water filter to send would end badly - the information is already defined elsewhere. The water filter itself would have to be written in with the water's code. The current setup uses a simple color overlay because that is far quicker/easier than what I just described and that code debt is the cause of this discussion. Implementing a new feature takes a lot of work and thought to ensure nothing fundamentally breaks, especially given that OpenJK is supposed to remain compatible with vanilla mods as much as possible.

[Archangel35757]

@@gerbilOFdoom, @@Xycaleth, @@Raz0r... the current water filter overlay is a hard-coded RGB value in Cgame, yes? The parameter holding this RGB value gets passed to renderer to be rendered (either Vanilla or rend2), correct so far?

 

Does the Cgame code then process the brush information & water shaders to the renderer for rendering? If so then it seems a simple method could be constructed to set the water filter overlay color RGB value to the specific water brush the player just dove into… and store this value into the parameter that holds the overlay. Initially draw it as dark gray or pale black (simulating eyes closed... if it takes a frame or two to compute the actual color).

[Xycaleth]

The cgame tells the renderer "draw this blue square on top of the screen". That's it. No water information, no brush information. Just a square.

 

https://github.com/JACoders/OpenJK/blob/master/codemp/cgame/cg_draw.c#L7776-L7805

 

This is the specific code. You can see that cgame is able to determine what kind of brush the camera is sitting in, and from that it tells the renderer to draw a square. cgame doesn't have access to any brush information, or shader information, or texture information.

[eezstreet]

It draws a colored rectangle if your view is underwater. That's basically the extent of what it knows.

All shader parsing is handled on the renderer. cgame can't sample textures. Brushes on cgame don't even have shader handles attached to them. What you're asking for as a solution is basically utterly impossible without restructuring the engine in ways that would break backwards mod compatibility.

 

I have an alternative idea. Add a new field to the worldspawn which controls global water fog color. It wouldn't be good if there's multiple different colors of water, but very few maps would take issue with this.

[Archangel35757]

It draws a colored rectangle if your view is underwater. That's basically the extent of what it knows.

All shader parsing is handled on the renderer. cgame can't sample textures. Brushes on cgame don't even have shader handles attached to them. What you're asking for as a solution is basically utterly impossible without restructuring the engine in ways that would break backwards mod compatibility.

I have an alternative idea. Add a new field to the worldspawn which controls global water fog color. It wouldn't be good if there's multiple different colors of water, but very few maps would take issue with this.

A blue overlay wouldn't fit when swimming underwater in a muddy river-- water color does vary. So what I am asking for would have to be handled by rend2... @@Xycaleth is that correct? ... with a boolean check in C game so that if renderer equals vanilla draw a blue square-- else draw nothing ( as this will be handled by rend2)

[Xycaleth]

Ignoring cgame's rectangle, yes, rend2 would have to handle this if it were to be done correctly.

 

EDIT: But this won't work with existing mods that have their own cgame. That's who we are catering for here. Existing mods.

[Archangel35757]

Ignoring cgame's rectangle, yes, rend2 would have to handle this if it were to be done correctly.

 

EDIT: But this won't work with existing mods that have their own cgame. That's who we are catering for here. Existing mods.

It could easily be made to work for existing mods with their own unique Cgames... just create a cvar, r_?, or other global varaible so that if false rend2 draws the default blue square (or whatever RGB color their unique Cgame passes to the renderer), but if true rend2 draws a unique color overlay that matches/compliments the current body of water, no?

[Xycaleth]

Not quite. The renderer has no context as to what the blue square is for. It could be for something other than water. Other mods may even try to draw something else instead of the blue square to make the water look better.

[Circa]

So what you're saying is, this can only be changed in mods, and won't be changed in OpenJK?

[Xycaleth]

Right. From what I can tell, there's no way of doing it reliably. OpenJK mods still need to maintain backwards compatibility with jamp.exe, and existing mods needs to be compatible with the OpenJK engine, so changing cgame is a no go.

[Archangel35757]

Right. From what I can tell, there's no way of doing it reliably. OpenJK mods still need to maintain backwards compatibility with jamp.exe, and existing mods needs to be compatible with the OpenJK engine, so changing cgame is a no go.

Interesting that Line#7797 says fix me and alludes to what I'm suggesting.

 

Correct me where I go wrong...

 

How does it break compatibility if OpenJK's Cgame customized this? If a mod doesn't use the openJK cgame then it shouldn't matter, right? So the CG_FillRect(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT, hcolor) invokes the renderer (be it Vanilla or Rend2) to draw the specified hcolor overlay.

 

Rend2 could have a user settable variable to either use the hcolor passed to it (by any mod's cgame) or else use a calculated color from a water Shader? Refer back to Line#7797.

[Xycaleth]

Rend2 doesn't know which square is for water, or if there even is a square for the water (like I mentioned in a previous post, a mod's cgame might do something different). You can guess which blue square it might be, but you might get it wrong, and end up ruining some mod's effect, and won't even work if cgame isn't rendering a blue square but a blue watery texture instead.

 

Modifying cgame itself doesn't break compatibility. Compatibility is broken with existing mods because rend2 now relies on that cgame change. If you load up JA+ in rend2, you will get the blue square (which you can't get rid of) as well as rend2's water effects.

 

EDIT: I think the best we could do is to add the fog effect in rend2 (without any colour), and let cgame tint everything blue. Still won't be great, but it would be better.

[Archangel35757]

If a water Shader was created (as alluded to... in Line#7797) that has a fog effect-- then the fog Shader itself can use a custom fog.tga, correct? And the water Shader could be used to determine the tint color overlay yes? But how would Cgame get this information from a water Shader to properly define the parameter hcolor?

 

What would need to be done to achieve this result?

 

 

You see the dolphins swimming thru the caustic effect... it also appears to have a "fog effect" to simulate underwater visibility limits

[DT.]

What about if the game points to say, a liquid.dat file that has all the liquid color values? This way, any mod can either use this file (which gets included with OpenJK builds) as-is for default colors or they can be edited. Would also be great if there's the ability to add new liquids without coding. Just an idea, don't shoot me.

[gerbilOFdoom]

I think I can solve all of these problems right now.

 

We simply need to make rend2 detect a variable set by cgame for whether or not to draw fancy water effects, then implement the fancy water effects from Unreal Engine 4 and, while we're at it, the rest of Unreal Engine 4's graphics system. 

 

Shouldn't take long since we have @@Scooper

 

#ScooperPlz

[Circa]

I think Xycaleth is gonna shoot us all.