rd-rend2 (old thread)

[eezstreet]

It compiles.

[Kessno]

What sort of benefits does rd-rend2 add to the lighting in the base game?

[eezstreet]

What sort of benefits does rd-rend2 add to the lighting in the base game?

https://github.com/ioquake/ioq3/blob/master/opengl2-readme.txt

[eezstreet]

some WIP screenshots

 

 

 

 

 

main menu

 

 

 

 

 

opening cinematics

 

Since JKA is designed to handle stuff at a 640x480 resolution, naturally it's going to fail like this when rend2 expects stuff at native resolution

 

btw, those of you on laptops such as a Toshiba Sattelite (which I've been using for benchmarking + tests) will experience a super long load time due to the GPU taking forever to load GLSL shaders...nothing I can really do about that though.

[Kessno]

Fantastic work! From that screenshot, I'd say that the opening cinematics rival that seen in modern game engines.

 

In all seriousness though, that's a great start. Due to the resolution, I can't tell if the font on the main menu is anti-aliased or not? I know when I've forced anti-aliasing through the nVidia control panel they typically aren't for whatever reason.

[eezstreet]

Fantastic work! From that screenshot, I'd say that the opening cinematics rival that seen in modern game engines.

 

In all seriousness though, that's a great start. Due to the resolution, I can't tell if the font on the main menu is anti-aliased or not? I know when I've forced anti-aliasing through the nVidia control panel they typically aren't for whatever reason.

No difference. And I don't know why font aliasing would be a big deal anyway, seeing as how each glyph gets pulled from a 256x256 grid, upscaled and then put onscreen. It's sorta the same effect as what antialiasing does anyway.

[ensiform]

The problem is that you didn't re-set the ORTHO code in rend2 to be like jka though, so its not really "native" either way.

 

RB_SetGL2D rd-vanilla does

qglOrtho (0, 640, 480, 0, 0, 1);

Stock Q3/ioq3 does it pretty much the same, except it uses the vid settings like rend2:

qglOrtho (0, glConfig.vidWidth, glConfig.vidHeight, 0, 0, 1);

rd-rend2 is doing:

Matrix16Ortho(0, width, height, 0, 0, 1, matrix);

Probably needs to be: (or at least if not FBO)

Matrix16Ortho(0, 640, 480, 0, 0, 1, matrix);

Using the vid settings makes it so that you must use the Adjust by 640 functions all over the place which is seen in q3 code in numerous locations.

[DT.]

 Matrix16Ortho(0, 640, 480, 0, 0, 1, matrix);

 

This works, but if you change the resolution then the screen will become black. If you restart the game however, the resolution is resized and working.

 

Also, rend2 is still using the "scripts" folder to look in for shaders.

[ensiform]

*Whistles*

 

 

 

[ensiform]

 

 Matrix16Ortho(0, 640, 480, 0, 0, 1, matrix);

 

This works, but if you change the resolution then the screen will become black. If you restart the game however, the resolution is resized and working.

 

Also, rend2 is still using the "scripts" folder to look in for shaders.

 

Yes but It MUST be done this way else you will have issues with the rest of the code.  (And its not that the changing mode causes it, just doing a plain vid_restart causes it too)

 

"scripts" is fixed but the parser is broken.

[Pande]

I think you're referring to HDR there. Bloom on its own is pretty much the same as JKA's dynamic glow.

The two do combine though, good HDR feeds into bloom so when the HDR makes the screen really bright the bloom acts on that. Plus JKA bloom is per shader but real bloom is pixel value based.

[Xycaleth]

The two do combine though, good HDR feeds into bloom so when the HDR makes the screen really bright the bloom acts on that. Plus JKA bloom is per shader but real bloom is pixel value based.

JKA bloom is also per pixel You just have direct control over which surfaces are 'bloomed'.

[DT.]

So what's the current status of rend2 (besides a "it broke" response rofl) for those who don't troll #jacoders or github like me?

[eezstreet]

Still working on it. Does not work yet. Working on getting Ghoul2 to play nice with the new renderer.

[eezstreet]

Progress! It doesn't crash when you get to the character creation screen, but it doesn't display a model either. We're making some ground here

[eezstreet]

Visual progress:

 

 

 

 

[DT.]

Great progress so far.

 

I noticed that when I hover over menu buttons, the colors change on the player model.

[eezstreet]

Great progress so far.

 

I noticed that when I hover over menu buttons, the colors change on the player model.

I didn't notice this, but thanks for pointing this out (!)

 

It looks like cgame/ui use different rendering flags from rend2 as opposed to the regular renderer. This is likely causing the majority of display issues.

 

(also @@Xycaleth should commit his fixes)

[Xycaleth]

I don't have any outstanding changes to rend2. All the changes I've made are already on in the repository.

[DT.]

Is OpenJK not liking rend2 lol?

[eezstreet]

@@DT85 Xycaleth realized that the renderer is not quite as powerful as once claimed. It uses FBOs/VBOs in very inefficient ways that makes no notable difference in game performance. So, until I figure out how rendering ought to work (or @@Xycaleth fixes it since he knows more about it than I do), I don't have any motivation to work on this.

[DT.]

ioquake3 rend2 is being updated, not sure what they are doing to it though.

[Raz0r]

We know =p SmileTheory was lurking #JACoders recently.

[Xycaleth]

Small update on this. I've been slaving away at this, to make it working better. Here's a few screenshots of what rend2 is capable of:

 

Notice the variation in shadows across the face of the lit rock surface. Rend2 can naively auto-generate normal maps using the textures you give it.

 

Dynamic shadows that affect all things in the map. It's a bit of an FPS as you can see, but this can eventually be optimised. (Ignore the Wampa with huge burn marks - GLM model rendering is still WIP )

[DT.]

Here's some green: