Some new ideas/code-usage for Quake

[gdiddy62]

Seven,
Looking at the texture of water from the pipes makes me think of the waterfall in the missionpack. I still do not like the texture of it. I see beautiful textures for moving water and waterfalls in games like Skyrim and want to move them into Quake. The water coming from the pipes here looks better than what we currently have in the missionpack. It needs to look more "fluid" and real than it currently does IMO. I wish my abilities would allow me to better help rather than just give lip-service. No -offense intended to those who have worked on it already. As I just said I'm giving lip-service and don't yet have the talents of so-many here.

[Mr.Burns]

Hi Seven,

As I think I've mentioned before, my current computer won't run DP in anything other than the most basic config so I will be unable to benefit from your work until I upgrade shortly. However, I just wanted to thank you for the effort you are putting in and the wonderful things that you are showing us that are possible within Quake. Hopefully one day soon I will be able to be appreciate these additions to the fullest extent, but in the mean time I wanted to express my appreciation and support and say keep up the good work.

Kind regards

Monty
P.S. Are you the same "Seven" that occassionally plays Runequake on Shmack?

[Seven]

Hello gdiddy,

You have the particle effect support in the mission pack "small mod compilation"�s already.
It is there since V3.5.

So basically all you need is available.
Now you can play around with it in R1M2.
As I mentioned above, I plan on doing a tutorial about it.
Until then, please look into the start or e1m1 map .ent files to see how it works.



Hello Mr.Burns,

Thank you very much for your post.
It makes me very happy to read it.
I have a moderate computer myself. It is the setting you adjust in main menu
and in your config file that helps to have good performance in DarkPlaces.
Setting everything to max is not a smart thing to do.
Taking the time and make the adjustments to your personal liking is better.
Important is to use a "good" DP build (in terms of performance).
And be sure to keep R_HDR switched off.
Special gimmicks, that only DarkPlaces has, like
- "offsetmapping"
- "Realtime litghning"
can be kept switched off too, because that is something you surely can dispense.
With that condition, I am very sure that you also can use DP and are able to
use several mods, that you maybe meant in your post (like "small mod compilation").

No, I am not the guy "Seven" that plays Runequake.
I dont play multiplayer at all. I dont even play single player.
In my freetime I love to play around with DP and QC.
My custom map list, that I want to play one day is already extremely long...

Kind regards,
Seven

[Seven]

Hello,

inspired by the map-model from RemakeQuake, I tried to include some too.
You can download them and use them freely. They are all Sitters models.
I only modified the textures.






I extended Nahuels code to implement models into maps via .ent files by some additional features:
Now you can decide wether the models will be solid or not.
On top of that you can set a custom setsize, or use the automagic measurement (via hullsize).

This is the new code:

.float sold;		// to make models solid
.vector sizemin;	// for setsize box
.vector sizemax;	// for setsize box


void () place_model = 
{
precache_model (self.model);
setmodel (self,self.model);
if (!self.sold)
	self.sold = 0;
if (self.sold != 1)
	self.solid = SOLID_NOT;
else 
	self.solid = SOLID_BBOX;
if ((!self.sizemin)||(!self.sizemax))
	setsize (self, VEC_HULL2_MIN, VEC_HULL2_MAX);
else
	setsize (self, self.sizemin, self.sizemax);
if (!self.count)
	self.count = 1;
self.alpha = self.alpha;
self.skin = self.skin;
self.scale = self.count;
};

This is an example for the .ent file entry:

{
"classname" "place_model"
"origin" "-95 1618 -210"
"model" "progs/box.mdl"		// box2
"alpha" "1"
"count" "0.35"
"angles" "10 -10 -45"
"sold" "1"
"sizemin" "-20 -8 -8"
"sizemax" "20 40 48"
}

This way it only takes a very short time to add models into your maps without editing the map itself.
You will find many many base map specific models (like these), or medieval or runic models there.


I made a small clip to show you the solid and non-solid map-models.
I used "r_showbboxes" "1" to better show the setsize of the models.
The pipes and boxes are solid, the gras and ferns are not_solid.
So you can walk right through the grass.
[ame=http://www.youtube.com/watch?v=ZG3IUNuApo0&list=UUbX7uVIXqMzBza0YmLJuMdw& index=1&feature=plcp]solid_and_non-solid_models_addon.avi - YouTube[/ame]

Have fun.
Seven

DOWNLOAD
(QC source, is included)

[FC Zvyozdochka]

Wow! this is truly nice! Looks more like Crysis than Quake

[golden_boy]

Mm, that is one option.

The solid_bbox stuff works to make mapmodels solid. It might be appropriate for some things, while clip brushes / func_nodraw might be better suited to others. Bboxes, for one thing, are always square while clipbrushes can take many shapes.

Supa just told me that for entity on entity collisions, bboxes can be as big as one likes, but since it is Quake, there might be glitches when using very large bboxes.

Any engine this is run in will also have to have the sliding on bboxes fixed.

As for the skeletons, thank you - I will probably model my own. =) I have downloaded those models though.

Are the steam vents a particle font, or did you use sprites? Have you tried both?

[Seven]

Hello,

seeing that in original Quake almost everything uses the classic bbox shape,
it was somehow guiding me to implement it this way.

If you want to do more complex boxes, then the .ent file entries will be too complex for the "normal" user. That was a suitable way of doing it... i hope/guess.
You only need to add 2 vectors now. This should be very doable for everyone.
If you still dont know how to do it, you can let Quake do it for you (via "hullsize").
That is of course less accurate, but it works very good.


Regarding steam:
Seeing what beautiful things can be done with particles, the choice was clear for me to use them. So I also made a QC modification to implement particles in any place in a map you want (fully customizable).
Source code and many samples are included in the download, if you are interested.
effectinfo.txt is unbelievable flexible and a sprite implementation is much more circuitous, stiff and "difficult".
You only need one single file for hundreds of particle effects (particlefont)
but you would need as many sprites for them.
Well, that limits us to use only a small amount of supporting engines, I know.
FTE and DP are as far as I know the only ones. Unfortunately they use a very different syntax and way of doing particles...
Not sure if Bakers engine support particles.


Regarding Slitters models:
Done let the preview�s on his website fool you.
They dont show every model, whiyh you will find in the pack.
Many packs have much more models inside.
You will also find chains, barrels and stuff there.

Thank you for your feedback.

[golden_boy]

You're correct that 100 different effects would need 100 different sprites, but on the other hand effectsinfo.txt needs Darkplaces, or alternatively a certain amount of code changes for other engines while sprites are easier to support (standard Quake supports sprites already, they just need to be high-resed which I think is much simpler to do than implementing the entire engine backend for effectsinfo.txt).

Effectsinfo.txt is easier to use for modders like you, but people like us in RMQ would need to implement the entire particle system before we could use it.

Sprites, for us, are much easier to implement, even if we use 20 or 25 different effects (not 100).

I am not detracting from your work, just explaining that different things can work better for different scenarios or applications.

We cannot just use darkplaces. Right now darkplaces doesn't even run our maps, and if it did (it will soon), the performance in DP is much worse than in RMQE.

We work with different maps, and in different environments that have different needs... as such, sprites could well be the better solution for RMQ, but we will see.

Just some philosophy, not to detract from your work.

[Lerster]

wow that's badass.

Its a shame i refuse to use DP b/c it still feels/looks different then proquake even wif the Proquake/gl quake setting.

But nice work dude.

[Seven]

Thank you for your posts and feedback.

Hello gb,
I am sorry, I maybe expressed myself not good (you know, my bad english...)
There is no doubt that sprites can also be beautiful and they are engine independent.

But I think a advanced engine like RMQ should also have at least some basic particle effect codes.
Just to use it for small things, that you can use anywhere without making a sprite animation.
I know, MH�s opinion about DarkPlaces...
But doesnt RMQ also have some nice new features ?
And doesnt other games with small steam here or secret sparkling there are nice ?
Of course nobody wants the overkill effects. Just subtle particle effects, that can be created quickly without animation code.
It would be highly flexible and can be used for various situations.
A particlefont is done quickly.

And yes, it must not follow the effectinfo script syntax from DP.
RMQ could make its own script syntax.

My opinion is, that particles with their ability to fade out slowly, be any "form (sparks, smoke, etc.) and its highly flexible usage should be (at least in a basic condition) part of every advanced engine.
A sprite can hardly reach the visual of a particle effect with a nice font in my opinion.


But we should not extend this topic too much.
Every engine dev has his/her clear view of how his/her engine shall look like.
And that is good !
If MH decides not to implement it in RMQ, it is good too.
It may be just a point worth discussing in your team.
I have of course no idea how much effort it is to implement the C-code for such a thing into an engine like RMQ.

Kind regards,
Seven

[FC Zvyozdochka]

particles with their ability to fade out slowly, be any "form (sparks, smoke, etc.) and its highly flexible usage should be (at least in a basic condition) part of every advanced engine.

Yes! RMQ Project really deserves such powerful particle system! In my opinion, it should fit this engine much better than sprites, I mean - in technical regard, especially now, when RMQ has pretty powerful decals system.

MH, I misunderstand your motives and targets. You are creating extremely fast engine with the most modern graphical API, why still you are creating vanilla style Q, after all those innovations in RMQ engine and playings with advanced Doom3-based offsetmapping?

However, no one could demand you to do what you don't want to, so I wish you good luck with what you are doing now!

I am sorry, I maybe expressed myself not good (you know, my bad english...)

Seven, gb, are both of you not from Germany?

[golden_boy]

Yes, 7 and me are both from Germany. I believe other Quake community members from germany are negke, Spirit, SleepwalkR, Rudl ...

It would be unfair towards others if we started talking in german amongst ourselves though.

About particlefonts in RMQ, we'll see. Many roads lead to Rome, what counts is the result.

[MH]

OK, here's my own motives for DirectQ summarized.

When I run Quake content I don't want something that looks like Quake 2, I don't want something that looks like Quake 3, I don't want something that looks like Doom 3. I want something that looks like Quake.

I've got nothing against particle systems, nothing against normal mapping and nothing against other effects; in the right place they're appropriate and look good. But I don't believe that Quake is the right place for them; especially with low-geometry id1 maps and low-poly id1 models they look really really bad - out of place, distracting.

The reason why DirectQ became so powerful and fast in the first place was nothing to do with it's intention; it's intention was just to be able to run Quake on a crappy laptop with crappy Intel graphics that I used to own 6 years ago. Having become this powerful means that you can still run Quake on this kind of hardware (although slightly less crappy than before) - but now you can run stuff like the Marcher Fortress, Warpspasm, etc and get good performance.

Part of it is also a slightly obsessive thing - just how fast can I make this go anyway? That's mainly for fun, but life can't be all serious.

DirectQ is a general-purpose Quake engine designed for running classic Quake content and meets that objective. RMQ is different. RMQ is designed around specific needs of running RMQ content and so can get to do many things in a different way.

At the same time -- I'm not setting out to recreate DarkPlaces. If that was what we wanted to do we'd just fork DarkPlaces, make the necessary adjustments, and call it a wrap.

There are other factors too. With DirectQ I get to say things like: "I don't care if it can't run on 10-year old hardware, this makes me more productive, it's fun and I get to play with shiny new features" (like using compute shaders for updating lightmaps). With RMQ -- I don't. RMQ needs to run on that old hardware or people don't get to play the mod. DirectQ can afford not to as there are plenty of alternatives available. Until such a time as the RMQ engine becomes obsolete there are no other alternatives available.

Part of being able to run on that 10-year old hardware is that you get to make all kinds of tradeoffs, many of which you'd actually rather not make. You get to say things like: "I'm not doing a fancy particle system that's only used in 10% of the game when the other 90% needs to run well - that's where the most useful work is". And horrible things like that.

So wow, that turned out a lot longer than I'd expected.

[golden_boy]

This is why I said earlier that (animated) sprites (hires ones obviously) might do in most cases in RMQ. They're a lot easier to do. But the cake is not eaten in any case.

The player does not care if a steam jet is technically sprites or particles. Much the same goes for rain. After all sprites are just images, much like a particlefont.

I'm not actually sure how much performance a particlefont eats. I'll have to look at it sometime.

[R00k]

I've got nothing against particle systems, nothing against normal mapping and nothing against other effects; in the right place they're appropriate and look good. But I don't believe that Quake is the right place for them; especially with low-geometry id1 maps and low-poly id1 models they look really really bad - out of place, distracting.

I'd have to agree with MH here, while my own engine project has bells and whistles, it cant carry a tune. With many of the different graphics features on modern engines, there just is not a cohesive gfx set / layout. It's all hodgepodge. But this is for Quake.

RMQ is different. RMQ is designed around specific needs of running RMQ content and so can get to do many things in a different way.

Mods are mods, and have a team that can control the art direction. There's nothing wrong with that.