"DP New-Lava" Thread

[webangel]

Just a joke.
Sure - everyone can try this when the textures are done.
Here is a video without the haze.
[ame=http://www.youtube.com/watch?v=LayexkeJ8Eg]Lava without Haze - YouTube[/ame]

[Roy Batty]

Looks great webangel! Me wants Me wants!!!!!

[talisa]

hmm looks interesting web@ngel.

yeah i can understand it is indeed hard to make something as lava look good in games. especially since you are dealing with a flat surface and thus itll always look kinda flat no matter what you try. but it looks not bad

could you perhaps try recording another clip without the lava-haze? it kinda makes it hard to see cuz you keep seeing the particles in front of the lava all the time


EDIT: i can has?

[gdiddy62]

Looks great Webangel!

[webangel]

Sevens great texture!

Hello @all,
I tried to make Sevens great texture looks more alive.
The lava is a hard thing.... - I guess (hope)...

If someone wants the textures please say some nice things!

I hope someone like this:
[ame=http://www.youtube.com/watch?v=qw6PdPq5OHg]Lava - YouTube[/ame]

[_Smith_]

You can make rain to appear less dense by spawning it less often and making rain drops less visible. I believe you can update snow/ash in similar way.

Here you'll find modified misc.qc, compiled SMCv3.8 progs.dat and two “demo” start.ent files.
One has two 64x64 blocks between normal and hard passages, left with old script and lowest possible “count””1”, and right with new default low density.
Second is whole start map made the new way and adjustable in autoexec.cfg with: set rain_density

Edit: This derail belongs rather to Splitterface's rain "work in progress" thread, but since it started here...
It is still better to avoid, when possible, making blocks smaller then 256x256 ( or 128x512 etc - area matters ), since rain will look marginally better that way. One trick is to extend beyond level geometry, other is to divide ares in more medium sized blocks ( stripes when needed ) instead of using one large and small blocks around it. If not possible, like isolated holes in the roof, the new code will handle it.

[Seven]

No, I did not dismiss, but it is simply not possible to extend small blocks beyond level geometry, when the roofcutout is in the middle of a map.

But as I said, it is a good idea Smith. Really.
It only leaves the most annoying issue untouched.
That is all I said

Having done so many maps with rain and talking with Roy Batty, Danicampio and splitterface about this small but important issue is telling me that this is the most weak point of adding rain into DarkPlaces.

If you look through rainy .ent maps you will see that almost all cubes have a value around "1".
That shows it.
But as I said, you need to do some complex maps yourself to "feel" the pain

But anyhow, it is really good to have the possibilty to use another method.

Thanks again Smith.

[_Smith_]

if (self.count < 1 ) count = 1; I've updated the code with a version that does that and makes it that “count” in .ent file really means “density”.
It works perfectly when you're rising density via cvar. When you are lowering density it makes smallest blocks to stay at count 1.

To eliminate or reduce this issue, small blocks can be extended beyond level geometry, higher default rain_density can be used.
Or the issue can be ignored, because if you try the new version you'll realise it is not really noticeable. I've tested start and e1m1 and it works fine imo.

It is compatible with existing .ent files, but new ones ( or modified old ones ) can take advantage of this feature.
Also, for a person who works on .ent file it is more convenient to work on densities instead of absolute counts.
I am surprised you've dismissed this so easily. Well, I don't care about rain much so I'll leave it now as it is. Maybe you'll rethink this

[Seven]

Hello Smith,

Good to see you back.

Unfortunately this will not change the issue with count<1 values.
As soon as the calculation will result in a count value<1 the rain is not spawned.
That was my concern.
It seems to be hardcoded in the engine.

I am not sure if you tried to create weather cubes for maps before.
The value "1" is good enough for big areas, but unfortunately you have to create small cubes many times to fully complete a roof cutout and you still have to use that big value of "1", which is for a small area much too much.

That is what I meant in my above post:
Even hardcoded values get ignored.

Example for your code:
Put this into start map:

{
"classname" "info_notnull"
"absmin" "400 500 -100"
"absmax" "500 600 400"
"nextthink" "0.1"
"think" "rain_init"
"dest" "0 0 -700"
"cnt" "2"
}

You need a cvar value of "7" to have a result count>1, so that the rain starts to fall.
So you always need a minimum cvar value for your cubes to be sure that the rain will fall.

And this makes the code and the idea to have a free choosable cvar value absolete !

It would be wonderful if LordHavoc gets rid of this minimum count value...
I have no idea why he added it.

But Thank you very much for your post and idea Smith !

Best wishes and hope to see you more often
Seven

[talisa]

cools, ill give it a try later, see if it works.

[_Smith_]

Well, Seven is wrong this time

Solution is in the unused func_rain() from dpmod. It has more functionality than we need and don't work with our ent files.
This simplified version is good enough for us, add it below rain_think() in misc.qc:

void() rain_init =
{
if (!self.dest) self.dest = '0 0 -700';
if (!self.cnt) self.cnt = 2;
if (!self.count) self.count = 1;
self.count = self.count * fabs((self.absmax_x - self.absmin_x)*(self.absmax_y - self.absmin_y)/65536);
var float autocvar_rain_density = 1;
self.count = self.count * autocvar_rain_density;
if (self.count == 0) { remove(self); return; }
if (self.count < 1) self.count = 1;
self.think = rain_think;
self.nextthink = time + 0.1;
};

autoexec.cfg: set rain_density 1 – default, 0 – will disable rain, you can use any value you want

Example ent file entry ( the first rain one in start.ent ):

{
"classname" "info_notnull"
"absmin" "276 404 -100"
"absmax" "812 764 400"
"nextthink" "0.1"
"think" "rain_init"
}

It is compatible with existing ent files: “min”, ”max” lines are unused I believe, “dest”, “cnt” lines are unnecessary unless you want values different than default.
"count" will work exactly like it works now, but you should use it only if you want different rain density in this particular spot ( for performance reasons, or on very tiny blocks, remember it is still affected by rain_density autocvar ). When count line is not present, default value will be calculated from rain block size.

To have uniform rain density across all levels “count” lines should be deleted or commented out and “think” values should be changed to “rain_init” in all ent files.

Edit: There was a bug in the fourth line: there was fabs missing -> self.count = fabs(...); it worked on start map and I didn't suspect this code can be incorrect

[talisa]

was already afraid of that...
shame you cant fix it and the rain code is engine-side and thus not changeable

[Seven]

The amount of rain particles is based on the area size.
That is how LH coded it inside his engine code.

void(vector mincorner, vector maxcorner, vector vel, float howmany, float color) te_particlerain = #409;

SSQC changes are ignored.
Even "hardcoded" count values get ignored.
Also count<1 values will not spawn particles.
Even when I delete the SSQC lines for that, the engine will not spawn any.
So, in short words, there is nothing I can do against the way it is done in DP.
I guess you would have to change the code in .c to do so.
As always, I might be wrong.

[talisa]

erm... lemme try explaining it in german what i mean. my german is not the best but people often tell me im better at it then i think. anyways, excuse me if i make mistakes

die regen ist heute calculiert wie 'grosse von regenblock geteilt durch angegeben wert'. kan es nicht errandert werden das es an stelle von calculiert wert wie 'regentropfen pro meter/unit'? wenn es so calculiert dan ist auch die regen in jeden block gleich, und is es nict das in sehr kleine blocken mehr regen ist dan in grosse, und dan kan man auch sehr kleine blocken brauchen sonder das es sehr viel regen ist in das block.

und wenn es so calculiert wert wie 'regentropfen pro meter/unit' ist es auch moglich es zufugen das die speler mit eine cvar selbst kan sagen von 'in die map wil ich so viel regen, und in die map so viel'

i hope that that makes it more clear what i mean, and that i didnt make to many errors

[Seven]

Interesting question.
Once I fully understand it (due to my bad english) I will think about it.