RiftQuake

[MadGypsy]

I wouldn't say your first health box was garbage but your new one is way better. I wonder if you realized while modelling it that you only had to model 1/4 of it and then mirror it on x and y. You should work on getting a good texture off of that box and then apply it to a cube (just like regular ammo/health boxes)

[Dutch]

I wouldn't say your first health box was garbage but your new one is way better. I wonder if you realized while modelling it that you only had to model 1/4 of it and then mirror it on x and y. You should work on getting a good texture off of that box and then apply it to a cube (just like regular ammo/health boxes)

Thanks buddy. Yeah, I did realize that about halfway through the model lol. Lesson learned, I'll be mirroring the next one. I like the depth this model has over a simple cube with a texture, but if it renders in-game and appears flat anyway, then this is the road I'll take to save on triangles. But this model is below the 2048 .mdl triangle limit.

[MadGypsy]

I wasn't even thinking about limits. I was thinking about holding on to your vanilla quake look/feel

[Sza]

@Dutch good job (nice shape) but i like even the first health box too. Give me the first model and i will show you why

... You should work on getting a good texture off of that box and then apply it to a cube (just like regular ammo/health boxes)

You mean to bake the details on a simple cube? If yes that would be a good idea.

Thanks buddy. Yeah, I did realize that about halfway through the model lol. Lesson learned, I'll be mirroring the next one. I like the depth this model has over a simple cube with a texture, but if it renders in-game and appears flat anyway, then this is the road I'll take to save on triangles. But this model is below the 2048 .mdl triangle limit.

Thats what i am saying all the time(adding a litlle bit details to a simple models and baking it as a normals...). I thought that you want to do the models in a old skool style after seven told you that my idea with the extra details as normal is not really good?

You must bake the textures (high or normal) with a good setup(may be u need to use some extra options or more "sesensitivity"? idk how it calls in professional language), otherwise it will be looking very flat (like you said)... so/and you need to use parallax in DP for better effect. I mean it will be looking the best with a parallax relief (is that the name?) shader but idk if dp supports it. It should look like a high poly. Something like here on the screenshot. People using the method to save performance. First example is doom 3 and some othe games My programmer flatter have found the perfect method for backing normals from modells which have not very much details. But he uses 3d max so idk how it goes with blender. He could bake normal or high maps 1:1... but anyway here is a small example.

The health box should look very good with paralax.

[Dutch]

I wasn't even thinking about limits. I was thinking about holding on to your vanilla quake look/feel

Got ya. I think I like a little extra detail now that I look at the new items. After updating most of them, I will look back and see if they look too out of place alongside the original monsters. I'm going to update every item so they should fit in. They still aren't high poly (maybe by traditional Quake standards they are) but if they are still small enough to accept .mdl format, I think I'm still within a good range.

@sza that's a slick example of what I could do, but I still want to remain within the realms of vanilla-style engines. The model I made still fits into QuakeSpasm quite nicely, and I used some fullbright edges to give it some depth.

Here's some pics of the textured health box and the small and large Rift Cell boxes. I listened loud and clear to the request for gritiness, so I hope they're to your guys' gritty standard.

EDIT: I am still going to include "clean" and "gritty" skins for each item, set by spawnflags to give mappers a choice based on their map's theme.

[Sza]

Okay i understand you. The first health box looks very nice even without normals good job

[talisa]

new health-box is looking good <3

.

rift cells however.... i unno, imo the large one looks ok-ish, but the small one just looks kinda ugly imo.
if you wouldnt have said what it was i wouldnt have had a clue wtf it was cuz it honestly looks like nothing at all....
its a... weird thingamajig with lights on it?

im afraid i wouldnt be able to help with any ideas what to do with it,
but imo the small rift-cell you have now is just yucky-looking

[vegetous]

woah thats f-ing awesum dutch! :d

pain-skins are neat and so are the additional animations,
and the death-animation looks great with the added arm-gib

+1

[Dutch]

thanks guys for the compliments.

@talisa thanks for the feedback, glad you liked the health box. For the rift cells, I'm not exactly sure what to do about those. I myself like how they look, I think they have an odd tech look that was never intended to look "normal". They're supposed to be based on reverse-engineered alien technology from the Slipgate Wars...that's all details from an episode I want to make.

I have a couple other model ideas for them that you may like better. Unfortunately, it takes me several hours (6-10) to render a single model of this size and texture it to where I think it looks fitting for both vanilla and advanced engines (it's pretty hard to walk that line, sometimes you want to go all out in texture detail and triangles, but you have to stop and remember your .mdl limits). The problem here is that I have at least 15 other models to build for ammo/new items, and I need to get back to coding/mapping before too long.

[Dutch]

Ok, I thought long and hard on what to do with the models. As of now, I have successfully modeled, textured, and coded 4 different health boxes, each with a clean and gritty skin set by spawnflags. I went ahead and added a small 5-health pack to the mod, along with updated versions of 15, 25, and 100. This means modified items, which means I'll have to go through and modify each of the vanilla maps. Not a big deal, because I intend to do this anyways for the new ammunitions. Remember, one of the goals was to keep the original campaign playable.

Now I'm working on the ammo box. Here's the plan: since each weapon will have its own ammunition, his would mean *14* box models, including big and small. I don't have time for this. I don't mean to rush, but I want to get this mod released before Quake 9 comes out. Lol. What I want to do is this:

* Ditch the big and small spawnflags and take the Q2 approach where there is only one size that meets in the middle of previous big and small values. This worked fine in Q2 imo, and the only benefit of having Big boxes is cutting down on entity load, which isn't really a problem in even the updated faithful engines.

* Use one generic box for all ammo types. Each ammo type will have it's own designated symbol textured onto the side and top of the box, as well as it's own fullbright color to stand out in the dark (ex: I use red for health and the medic cross for the symbol).

* Ditch the old Rift Cell models and use the above-mentioned method. I value talisa's opinion on that, as she is a badass modeler. Also, the more I look at them, the less satisfied I become with them.

* Create alternative models for each ammo and health type for Deathmatch that will float, rotate, and look much like the Q3 items. This will make each type easy to identify right off the bat (since DM is more chaotic and fast-paced than SP) and will also be easier to spot. They will also ditch the "drop to floor" command so mappers can place them in midair.

I'll throw some pics up later, but I'm gonna hit the sack now. Lol. Let me know what y'all think.

[Spike]

use .scale for different sized ammo boxes or something. saves modelling time, preserves some variety.
just using different angles on ammo boxes will probably help. most of them end up axially aligned, which is often quite silly.
one big thing with quake3 is how all the different weapons+ammo have their own unique colour. you can figure out what it is at a glance despite them all being the exact same shape.

[Seven]

Hello Dutch,

I am not sure, if you still hold on your idea to keep the mod engine-independent.
If yes, do what Spike and yourself suggested, as it is a great way of saving models:
Use .scale

That needs "engine-detection qc code" though, as it is an extension. Which is possible.
You should do that once in your qc, set a dedicated float accordingly, that you can always check when it comes to an engine specific "feature" somehwre in your qc.
Sock and Necros both do this in their mods, too.
I would love to do this as well, but unfortunately I went the DP-way for too long and cannot easily switch now.


The idea of using dedicated colors for each weapon/ammo set is looking and doing great in Q3, yes. I am not sure if that colorful approach also fits to Q1 and your mod.
But it would be an additional way to make things easier indeed.

The idea for "using one generic box for all ammo types. With each ammo type having it's own designated symbol textured onto the side and top of the box" shold be considered last and only if everything else doesnt work in my opinion.


One more idea that combines 2 others would be:
Use Spinning ones as "big ammo" and not spinning ones as "small ammo" of that ammo type. That works even with vanilla qc and might be a good combination of saving models and still makes them very good distinguishable.

Best of luck.

[Dutch]

Thanks for the feedback you two.

use .scale for different sized ammo boxes or something. saves modelling time, preserves some variety.

I thought about that, and having heard from you and Seven about it has convinced me to go this route. I just didn't want it to look like I was cutting corners.

just using different angles on ammo boxes will probably help. most of them end up axially aligned, which is often quite silly.

Are you referring to the fact that they are always basically parallel to each other without rotational placement? Canting each one off a couple degrees in different directions would add some realism.

one big thing with quake3 is how all the different weapons+ammo have their own unique colour.

Exactly what I was envisioning as well. I may BSP these models so I have the full palette to work with, and not just a handfull of fullbrights. Basically the idea is, like you were saying, make them stand out in DM. So, shoot for functionality in DM and for visual effect/realism in SP.

That needs "engine-detection qc code" though, as it is an extension. Which is possible.
You should do that once in your qc, set a dedicated float accordingly, that you can always check when it comes to an engine specific "feature" somehwre in your qc.
Sock and Necros both do this in their mods, too.
I would love to do this as well, but unfortunately I went the DP-way for too long and cannot easily switch now.

It sounds like I'm a about to trip a land mine here haha. Can you elaborate a little? Not totally sure what you're referring to for engine detection, do you mean the scale? I didn't know you could scale things in code if so. I was just going to re-scale in qME after I Blender'ed the boxes. The resolution of the texture shouldn't warp too much because my 'Big' boxes won't be any bigger than the small boxes from vanilla Quake. That, and I usually use a 256x256 resolution, which is within .mdl limits but much larger than what id originally used on their boxes (which were mips within a BSP).

The idea for "using one generic box for all ammo types. With each ammo type having it's own designated symbol textured onto the side and top of the box" shold be considered last and only if everything else doesnt work in my opinion.

Thanks for your thoughts. I will play around with it and see how I feel about it after modeling the q3 DM-style models. Then I'll see what you guys think.

Right now, however, I have to finish a final term paper So the project's on hold for tonight.

[Spike]

much of the time you can code things such that you don't have to care about whether the engine actually supports it or not. if you make your models such that they have a mins_z position at 0 (that is, the entire model is above the z=0 plane - the bsp ammo models all have this property) then you can just set self.scale without caring if the engine supports it, so long as your setsize stuff is done properly.
if (cvar("pr_checkextension")){thecheckextensionbuilt inissupported();if (checkextension("DP_ENT_SCALE")){thescalefieldissu pported();}}
the rest is juse a case of writing it sanely and knowing the names of the extensions. and luck - just because an engine advertises it doesn't mean it isn't buggy or has some liberal interpretation of what its meant to do.

[Seven]

Hello Dutch,

What Spike said.
Regarding the "engine detection", you can only detect an engine via its extensions (which should be unique to really 'detect' an engine, or rather detect an *extension*, to know if this engine supports it).

You should therefore take a look into the engine� extension lists:
DP always includes its extension list in the .zip download (it is called dpextensions.qc).
FTE has a fteextensions.qc, but you have to download it separately:
http://triptohell.info/moodles/fteqcc/fteextensions.qc

dpextensions.qc has lots of comments, examples and descriptions for its extensions, which is really useful for beginners like me.
This is what it says about checking extensions via qc:

//checkextension function
//idea: expected by almost everyone
//darkplaces implementation: LordHavoc
float(string s) checkextension = #99;
//description:
//check if (cvar("pr_checkextension")) before calling this, this is the only
//guaranteed extension to be present in the extension system, it allows you
//to check if an extension is available, by name, to check for an extension
//use code like this:
//// (it is recommended this code be placed in worldspawn or a worldspawn called function somewhere)
//if (cvar("pr_checkextension"))
//if (checkextension("DP_SV_SETCOLOR"))
// ext_setcolor = TRUE;
//from then on you can check ext_setcolor to know if that extension is available