Since I use the Current svn build for testing I get a sparklies firework in Cleft Village (in Beta 1 as well as in newer test versions), which never happened in 2.4.2.
The interesting thing is that they also appear at places where there is no triangle or texture border.




The map has been compiled with the patched q3map2 (NetRadiant).
They appear on textures that are not connected with shaders, esp. not "cull none".
It also happens with the standard config.cfg
Maps with patches (like bluesky) are not affected.

Does anyone know how to fix this (or what causes it)?

There has been changes in the way deluxemaps are processed in SVN (to make sure deluxemaps don't decrease average brightness too much). How old is your NetRadiant build (q3map2 did receive an update to generate proper deluxemaps for the new deluxemapping)?

Ok, I compiled the latest revision of NetRadiant (and with it the map), but it didn't seem to help...

I will experiment some more, because it only seem to affect cylinders (and only the ones bend "outwards"), but not all, for whatever reason. So it seems there is something wrong with the models.

Well... you can always try doing this:

- Remove "cull none" from their shader. That is the one thing that triggers the bug.
- To make it visible from both sides, make two brushes, one for each side you want to see it from. In case of the cylinders, you probably won't need this.
- Make sure that stuff that should not pass light has _castshadows set to 1 as entity key, and that its shaders do not specify "surfaceparm trans".
- Always compile with -patchshadows. Why isn't that default?

sev wrote:They appear on textures that are not connected with shaders, esp. not "cull none".

divVerent wrote:- Remove "cull none" from their shader. That is the one thing that triggers the bug.

I was able to fix it, at least I hope so .
This only seems to affect cylinders in ase models, and the problem does not seem to be single sparklies, but "cracks" that cover the whole length of the cylinder (and also occur in other maps, like arboria_v2r3).



The main cause is the key "spawnflags" "4" (and every value that includes 4, i.e. 6).
And in one model, no matter what spawnflags I used, the problem also occurred when I exceeded a certain number of triangles.

Try using spawnflags "5". "1" adds shadow casting to the map, with "4" together it may cast shadows on itself and prevent this bug. If you confirm that this helps, I'll add it to the entities docs.

So there is a function for "1", I wondered about this.
Sadly, spawnflags "5" doesn't help.
But I fixed the map anyway, I simply don't use spawnflags 4, or only on models without cylinders.

maybe its texture compression messing things up?

next try is spawnflags "5" AND _castshadows "1" AND _receiveshadows 1... to make sure

divVerent wrote:next try is spawnflags "5" AND _castshadows "1" AND _receiveshadows 1... to make sure

Sadly doesn't work either.
But it shouldn't be too much of a problem anyway, I only have seen it in very few maps, and I fixed it in mine.

Ran into the same thing, it looks like its trigged by a change in how darkplaces handles deluxe maps. revert to rev 8515 of darkplaces and you good to go.

Well, the revert won't happen in the darkplaces trunk, so please do not rely on that (as that reopens the other old bug that the same places always get black... not exactly better). Work around it in your map until the bug is fixed in the map compiler.

This is clearly not an engine bug, but it happens now when the deluxemap vector the map compiler wrote is a zero vector.

First of all, try again using CURRENT NetRadiant, i.e.
http://emptyset.endoftheinternet.org/~r ... -win32.zip
or later. I fixed a bug causing stuff to receive light from the wrong side in that. You may be using an older q3map2, which causes this.

Secondly, if this does not help, please supply the .map file and ALL required content that's not in Nexuiz svn to me, so I can debug it.

Thanks

One instance of this is caused by a bogus normal vector, pointing INTO the triangle instead of OUT of it. May happen when smoothing normals. See how the blue normal below the spectator text points DOWN.

Any instance of this when NOT smoothing normals, that is, using mere brushes and not q3map_nonplanar?

Any instance of this when q3map2 does the normal smoothing, that is, using mere brushes and q3map_nonplanar instead of making the normals in the modeling app?

Proof that this is a q3map2 problem:


Surface normals of the model.


Surface normals as seen by q3map2.

These normals mismatching (because q3map2 downsamples them into a bitmap, instead of using their exact values), and deluxemaps being in MODELSPACE, causes these problems.

But as Id Software don't care for q3map2 bugs, and I gave up debugging this (any attempt to fix the normals q3map2 uses leads to black spots on the lightmaps/deluxemaps, for no imaginable reason), this will NEVER GET FIXED.

Thank you, for never helping out.

I can't do everything alone.

And when it goes on like this, I will leave and the project will die. Because you guys never help.

We need people to help with the project (in NetRadiant too, as you see here), but as this is never going to happen... it'll be the end. I wonder if there will ever be a next version, given the current state of the project.