Beta Testing 2.08

[lowenz]

Water sprays texture issue (Siege Shop)

[grayman]

14 minutes ago, Springheel said:

If that's the newspaper gui I made for New Job, it isn't set up to use page corners as it's only meant to be a single page. 

No way to shut down the WARNING spam?

[Springheel]

1 hour ago, grayman said:

No way to shut down the WARNING spam?

I'd have to relearn how guis work to even guess at what's causing it.

[grayman]

May I take a shot at it?

I'd produce a local copy of the gui and manipulate that, so as not to bother other mappers.

[Springheel]

Certainly!

[cabalistic]

7 hours ago, lowenz said:

Water sprays texture issue (Siege Shop)

Hm, looks fine on my end, Can you provide your hardware specs and darkmod.cfg?

[nbohr1more]

2 minutes ago, cabalistic said:

Hm, looks fine on my end, Can you provide your hardware specs and darkmod.cfg?

You tested with this version:

https://drive.google.com/open?id=1sF6wlXqETcBVp_xPJxqOj6J1lt4s5scI

?

[cabalistic]

21 minutes ago, nbohr1more said:

You tested with this version:

https://drive.google.com/open?id=1sF6wlXqETcBVp_xPJxqOj6J1lt4s5scI

?

No, I tested with the one from the ingame download list. This one does show the issue, but it's also broken in 2.07 for me. Looks like that softparticle has no texture, so it's getting rendered with _default - hence why it's black.

[PranQster]

11 hours ago, lowenz said:

Water sprays texture issue (Siege Shop)

Repaired in siegeshop by switching to a different particle. Several of the water splash particles do this, including the ones starting with 'tdm_'. I switched to a large steam particle instead. OMG I hope I put it in the .pk4  Time to repack and update the link.

And I have been delayed by a suddenly misbehaving ragdoll in the dungeon. That guy stayed put for years, lol.

The .pk4 linked in my FM post now has the steam particle added. I'll have to run it to check the ragdoll.

Edited April 29, 2020 by PranQster
ragdoll misbehavior

[stgatilov]

Could someone tell me please if these problems were fixed or not:

Quote

3. @Goldwell: werebeast assets confusion (link followup).
13. @VanishedOne: Cannot spawn werebeast (link).
12. @VanishedOne: Many errors on clothed zombie (link).
14. @Goldwell: A pack of assets with missing textures (link).

 

[PranQster]

Is it possible to suppress warnings on static_entities which have a "bad rotation matrix"? I often re-size models on at least one axis by modifying the rotation values, so I end up seeing a lot of these errors when doing dmap.

[nbohr1more]

14 minutes ago, PranQster said:

Is it possible to suppress warnings on static_entities which have a "bad rotation matrix"? I often re-size models on at least one axis by modifying the rotation values, so I end up seeing a lot of these errors when doing dmap.

Not to be a Debbie Downer but please "don't" use the rotation hack to rescale models.

Please use the model scaler feature in Dark Radiant:

 

https://wiki.thedarkmod.com/index.php?title=Model_Scaling

 

 

[stgatilov]

1 hour ago, PranQster said:

Is it possible to suppress warnings on static_entities which have a "bad rotation matrix"? I often re-size models on at least one axis by modifying the rotation values, so I end up seeing a lot of these errors when doing dmap.

No. If you use this "feature" (BTW, I guess this was never supported by idTech4), then live with warnings

As far as I remember, all func_static-s in a map produce a single warning, with up to 10 names listed in it. So the spam is very limited. But if you have bad rotation on anything else, then every entity is reported individually.

We have some discussion on a design of embedded model transformation (including scale and skew), but did not come to conclusion yet. Be prepared that in some future bad entity rotations will be forbidden completely. By that time there should be some convenient replacement.

[PranQster]

1 hour ago, stgatilov said:

No. If you use this "feature" (BTW, I guess this was never supported by idTech4), then live with warnings

As far as I remember, all func_static-s in a map produce a single warning, with up to 10 names listed in it. So the spam is very limited. But if you have bad rotation on anything else, then every entity is reported individually.

We have some discussion on a design of embedded model transformation (including scale and skew), but did not come to conclusion yet. Be prepared that in some future bad entity rotations will be forbidden completely. By that time there should be some convenient replacement.

Ok. Thanks. I already know of a few models which didn't exist when I started some maps, and do exist now (such as hanging coil of rope). So I'll work on replacing such entities.

[PranQster]

3 hours ago, nbohr1more said:

Not to be a Debbie Downer but please "don't" use the rotation hack to rescale models.

Please use the model scaler feature in Dark Radiant:

Ok. I never knew there was such a feature. Thank you.

[grayman]

3 hours ago, stgatilov said:

Be prepared that in some future bad entity rotations will be forbidden completely. By that time there should be some convenient replacement.

TDM Support for existing maps using the hack should remain. We can’t break old maps.

Removing the hack for new maps needs to be done in DR.

[stgatilov]

beta208-05 has been released.
The list of changes is provided in its usual place.
Remember that you must download tdm_mirrors.txt again from the link in the original post before running tdm_update.

[nbohr1more]

As a reminder, a good practice is to delete your darkmod.cfg after every beta update and reset settings.

In this case, if you don't set r_useMultiDraw to "0" after updating to beta 5 you will see all sorts of broken rendering.

[grayman]

6 minutes ago, nbohr1more said:

As a reminder, a good practice is to delete your darkmod.cfg after every beta update and reset settings.

In this case, if you don't set r_useMultiDraw to "0" after updating to beta 5 you will see all sorts of broken rendering.

If this is a required setting, why offer the option of changing it? Shouldn't even be archived.

[nbohr1more]

I think that the intention is to fix multidraw by the next beta?

[stgatilov]

16 minutes ago, nbohr1more said:

In this case, if you don't set r_useMultiDraw to "0" after updating to beta 5 you will see all sorts of broken rendering.

False alarm.

Duzenko has removed archivable flag from this cvar. That's a good way to force users to a new value.
I'm not sure he will restore multidraw in 2.08, but if he will, he can return archivable flag back, along with default "1" value.

[nbohr1more]

I had to set it manually on first run. I guess if I had restarted it would have self corrected?

[stgatilov]

1 hour ago, nbohr1more said:

I had to set it manually on first run. I guess if I had restarted it would have self corrected?

Hmm... yes, perhaps you are right.
I had some weird blackness on the first test of the new beta, but could not reproduce it after that.

[duzenko]

38 minutes ago, stgatilov said:

Hmm... yes, perhaps you are right.
I had some weird blackness on the first test of the new beta, but could not reproduce it after that.

That should explain it

@nbohr1more

No, multidraws aren't worth it the way I implemented

You need to clip to void to start getting 3% difference

It seems the driver is doing a good job batching draw calls already

Let's see how @cabalistic will do it in 2.08 but generally there is little chance to get capped by draw calls/driver in 2.08 already

[cabalistic]

1 hour ago, duzenko said:

That should explain it

@nbohr1more

No, multidraws aren't worth it the way I implemented

You need to clip to void to start getting 3% difference

It seems the driver is doing a good job batching draw calls already

Let's see how @cabalistic will do it in 2.08 but generally there is little chance to get capped by draw calls/driver in 2.08 already

Hm, actually draw calls are very clearly starving the GPU because the CPU overhead per draw call is way too high. It's just that, if you have com_smp enabled, it is almost completely hidden behind the fact that the frontend takes a very similar amount of CPU time. But since the frontend also has some clear potential for improvement (mainly stronger parallelization), optimizing the drawcall overhead is definitely worth our time But yeah, I think I know how to approach this, so let's postpone this after 2.08.