New DarkPlaces beta released

[jakub1]

to seven:
-
i tried one of the latest autobuilds for these pictures. not exactly the very last one available 'cause this one doesn't work for me at all. when i start quake with this one i can see nothing but a black screen - no menus, no quake.. nothing.
-
i also tested autobuild dated from the 3rd february 2011 (your link to quaketastic from this thread), but a result is the same. map forward compatible has strange light issue as well.

[Spinvis]

to seven:
i tried one of the latest autobuilds for these pictures. not exactly the very last one available 'cause this one doesn't work for me at all. when i start quake with this one i can see nothing but a black screen - no menus, no quake.. nothing.

I can confirm the issues in the newer autobuilds, latest beta2 works for me tho. However mine just crashes completely. So far i have discover it has something to do with some settings in my config, but i haven't had the time to check which setting it is exactly and posting a bug report for it. If i delete my autoexec and config and start "clean" it works normally. Maybe something you can also try and see if that works.

[Seven]

Spinvis & jakub

not a suprise for me.
Autobuilds are autobuilds. Not betas and not finals.
So using them is always at your own risk.


But jakub, please answer my question from post #30 on page 4.

Thank you,
Seven

[jakub1]

hi seven,
-
sorry for delay. i've just finished testing in rub2m2 and the final results are:

darkplacesengine20100831beta1 - the flag is black/strange shadows on the wall behind the flag/turrets (not the turret model itself, only the source of the shooting) are moved aside from their originals locations

darkplacesengine20101121beta1 - same problem as above

darkplacesengine20100408 - official stable version - the wall behind the flag is ok, other problems remain.

all versions tested in fresh new q1 installation, no custom cfg, no hires stuff, just q1 and rubicon2. shadows are fine when realtime lighting ON in all versions of dp, however the turret problem is still there. it's not a surprise for it has nothing to do with lighting.

rubicon2 is really slow with all these versions. lord havoc must have worked hard on engine speed recently.
-
jakub

[LambentHammerBurst]

Sounds like the turret laser has a bug in Darkplaces much like the Plasmagun in Mission Pack 2 did. May be nothing you can do unless you edit the progs.dat

[jakub1]

you're right, but strange is that the other turrets in the same level work fine. i know about several levels in which various movable segments (lifts, bridges ets...) are moved aside in the same way.

[Seven]

Thank you for your effort to make the test jakub.

If I understood your words correctly, most of the issues you encountered are identical since august 2010.

Thats at least a good sign.
So my suggestion to use the build from 3rd february 2011 makes sense due to performance increase.


One last word:
I know that divVerrent (aka div0) is very hardworking on DarkPlaces development lately.
It is a good thing and helped to boost the performance significantly.

Best wishes,
Seven

[Spinvis]

Two new betas have been released, you can find them on the usual location. So far in my short test this has fixed my crash issue with my custom config and autoexec. It's running stable and fast, so a keeper for me, until a new beta or final comes out.

darkplacesengine20110328beta2.zip
darkplacesengine20110328beta1.zip

[Cobalt]

Will have to try the new betas. I have told Lord havoc about some bugs I found where the flags in CTF do multiple captures...something to do with movetypes and touch calls. I also do not see the runes showing up on the hud when picked up, and after I renamed a modified player model to something else, its saying its an unsupported type.

Forgot to tell him too that the bubble.spr ought to not pass through solids - as when you are underwater, and they pass through bsp to get to surface of water....same thing with the lava spray particle effect - it seems to bleed / pass through walls when its launched too close to one. They would make good cvars at least

[LordHavoc]

I still do not understand what issue is being illustrated...

I did find one bug so far - that the quake models (without any replacement textures) seem to be immune to offsetmapping for some reason, only the walls get offsetmapped with quake textures... Not sure why, but investigating.

[Seven]

Hello LordHavoc,

thank you for posting here and try to help to find the reason for this issue.

The problem is:
When you enable offsetmapping:
"r_glsl_offsetmapping" "1"
and your external model has only a diffuse texture and NO offset texture (such as _norm),
your engine build�s from 13th february 2011 till today have the issue shown on the screens.

My-Key (creator of QRP�s normals) described the issue with these words:

I supose that newest builds have bug with parallax mapping and if texture doesn't have normalmap engine probably creates flat bumpmap. The easiest fix is to make "flat" normalmap without alpha channel.

It looks as he is right.
The models look like an external offset file with wrong alpha channel exists.
This would lead to the same effect as shown on the screens.

If you HAVE a external offset file (_norm), the model looks perfect as it should !

So the problem only occurs when using "r_glsl_offsetmapping" "1" and NO external offset file do exist.

In your DP builds until 3rd february 2011 this issue does NOT exist.
That is why I use this build (because I always enable r_glsl_offsetmapping, but dont have normals for every model I use)


Here are new screen comparisms (taken with beta2 build from 28th march 2011)
I deleted the external normal textures for the models to show you the result:
"r_glsl_offsetmapping" "1" / "r_glsl_offsetmapping" "0"

/
(please look at ammo box + weapon)

Thank you for your investigation LordHavoc.

Kind regards,
Seven


PS: I tried your autobuild from 8th april 2011 now too:
The offsetmapping feature seems really broken now.
The world textures dont show offset when using the "r_glsl_offsetmapping" "1" now (even though normals do exist).
The world textures offsetmapping still worked in beta2 from 28th march 2011.

[LordHavoc]

PS: I tried your autobuild from 8th april 2011 now too:
The offsetmapping feature seems really broken now.
The world textures dont show offset when using the "r_glsl_offsetmapping" "1" now (even though normals do exist).
The world textures offsetmapping still worked in beta2 from 28th march 2011.

There are 3 cvars involved:
r_glsl_offsetmapping - enable/disable offsetmapping on things that have it enabled
mod_noshader_default_offsetmapping - enable/disable offsetmapping on replacement textures
mod_q3shader_default_offsetmapping - enable/disable offsetmapping on q3 shaders

I am still unclear what your desired behavior is, the r_shadow_bumpscale_basetexture cvar is what is creating offsetmapping effects on the diffuse texture, this is overridden by any _bump.tga or _norm.tga that is found.

If you desire offsetmapping to never be enabled on basetexture (diffuse converted to normalmap), only enabled if bump or norm are present, I can do that.

After my changes on the 8th the offsetmapping is disabled on all quake textures (not replacement textures).

So if you could answer the following, perhaps we would be on the same page on intended behavior:
1. do you want offsetmapping on quake map textures (not replaced)?
2. do you want offsetmapping on quake model textures (not replaced)?
3. do you want offsetmapping on map replacement textures that lack _bump and _norm files?
4. do you want offsetmapping on model replacement textures that lack _bump and _norm files?
5. do you want normalmapping on quake map textures (not replaced)?
6. do you want normalmapping on quake model textures (not replaced)?
7. do you want normalmapping on map replacement textures that lack _bump and _norm files?
8. do you want normalmapping on model replacement textures that lack _bump and _norm files?

I can cvar all of these things, I'm more curious about defaults.

[LambentHammerBurst]

"If you desire offsetmapping to never be enabled on basetexture (diffuse converted to normalmap), only enabled if bump or norm are present, I can do that."

I think that'd be the best option. I myself didn't notice the bug Seven was having until I ported the Dopefish from Daikatana to replace the Rotfish - and it looked distorted until I made a 8x8 texture for the normal map which was just solid green.
The idea was great, however it needs to have a cvar for it to be on or off and then split into the categories you mentioned.
I myself would say anything model related - should be off by default. Map textures can go either way, I would say to leave off by default too. People generally use Darkplaces to get the High Def Quake - so they'd (usually) be replacing the textures.

One thing I would do though is add the 8 options to the options menu - there needs a update as there's many options that go unnoticed as they don't know it exsists as it's absent in the menu.

[Seven]

Hello LordHavoc,

Thank you very much for your answer.

In my opinion it makes no sense to have offset- or normalmapping on default ID1 Quake models/textures.
There are no offset-files for them in orig. Quake.
So you would only "fake" an existing offset texture.
The visuals will be not good

Only if external offset files (_norm or _bump) are available, then they should be used, when enabling "r_glsl_offsetmapping" "1".
This is exactly the way it was until 3rd february 2011 build.

After this date things changed. In my opinion to a not good way.
"Faking" normal textures for a diffuse (external or original ID1) texture will always result in a not good visual (see screen in my post #41 above).
Look how long it takes to create a external normal texture by hand.
An automated software emulation will never reach its visual.
I know there are other engines, that "try" to do just this.
But the visual is always not good in my opinion.


So going back to the way things was handled till 3rd february is my favorite:
If you dont have any external offset textures and enable "r_glsl_offsetmapping" "1",
you should not see any difference to "r_glsl_offsetmapping" "0".


Maybe I am completely wrong with my opinion.
But working on visual enhancements for DarkPlaces for a very long time now,
makes me believe that this is the best solution.

Thank you for your time reading this.

Best wishes,
Seven

[Seven]

... another thing that came to my mind (refering to OoPpEe�s post above).

The main issue, people have when using DP is, that some quite important options are not available in the in-game menu.

Offsetmapping is one important example.

I suggest having suboptions for it as follows:
- enable offsetmapping
--- emulate offset textures
--- enable reliefmapping


One last word regarding the thing I wrote about "emulated offset textures" in my post above:
Amazing external normal textures are available from QRP and Rygel.
Installing them is very easy.
Together with external diffuse textures from QRP or Rygel they make a nice visual.
The need for emulated offset textures are in my opinion not necessary.
But if people want them (if they dont have external ones), they can enable the suboption I described above.
Anyway, emulating offset textures for stock ID1 textures seems quite overdone, because of the low resolution.

Kind regards,
Seven