That seem to be the right solution, they all roll now.
void() vibro1_start =
local float r;
if (self.pain_finished > time)
self.pain_finished = time + 1;
void() info_vibro =
self.solid = SOLID_BBOX;
self.movetype = MOVETYPE_NONE;
setmodel (self, "progs/vibro04.mdl");
setsize (self, '-4 -4 -4', '4 4 24');
self.use = vibro1_start;
For my humble request, the same macro is used by the turnwall. But it needs to start and stop.
How can I make it toggable?
create two functions vibro1_toggle_on, and vibro1_toggle_off
The "off" function needs to set nextthink to -1, and set "use" to vibro1_toggle_on
The "on" function needs to set nextthink to time + 0.1, and set "use" to vibro1_toggle_off
Finally, you need to add a line to vibro1_start which sets "use" to vibro1_toggle_off.
Damn, you trying the recreate chasm levels inside quake? I don't think the chasm levels are that good, only thing worth salvaging are the monster and weapon models.
I'm starting to believe my own lies, yes that's the way to do it.
Now I can spin down the fans at commands. Really thanks for the hint.
Usually I get cramped by warnings but this time the algebacary is on my site.
yeh1, the levels may not be that good, but what if I use the buttom to go under to furnish the refinary and jump in a fan tunnel?
Chasm monsters deserve a well arrayed terratory.
I wish I could lay my hand on that alfa_mask texture. I'm using static fences
, as they are the only way for me to obtain transparancy.
I like the theme behind Chasm maps, but they are too tiny (you don't have space to run/maneuver) and, like old doom maps, they aren't 3D (you don't have vertical action).
Would be better if you stick with the theme, but not with the old limitations/architecture. Think of it more like a remix than a remake.
I'm trying to give Stratos a quakey apearance with chasm effect.
So I attached the scrag attack to its needs and changed the w_spike into a circle sprite.
It is shooting round sprites now, but the positioning is a little out of centre.
Also it shoots them one after another, nor at the same time.
If I recall correctly, that huge robot from AD fires two rockets at the same time, as does the centroid from mission pack 1, couldn't you look at their code?
I could take a look at the soa.qc.
For now I'm puzzled by the shooting range of the scrag which comes in a v shape from the scrag towards the player.
Stratos fires exact in the opposite way.
The V shape is an illusion created by the particle effect on the scrag spit model. If you replace w_spike.mdl with the rocket model you'll see how the smoke particles give a clearer indication of the way the spike moves. It's really just a single object moving in a straight line from scrag to player.
That's the same outcome when I use a sprite in stead of the w_spike.
My intention is to make it look more like the Stratos attack, ie. starting at the same time on both sides.
I've got the idea the sprite won't come up for nine frames, only the first one
is used. That doesn't give it the facet look like a sequence of rings.
The railgun from dr shadowborg uses this sequence, I just don't know how to intergrate it.
I'm trying to convert the Chasm weapons to quake.
For the shotgun I just used the w_rifle.mdl for the shotgun.
Now I'm trying the double shotgun and it works in the same way.
There is just one thing I can't understand, when I try to use the g_rifle in stead of the g_shot for static it falls just below the surface.
I can heighten the static in the map or in the origin of the mdl, the thing just falls in ground.
What can be the reason of it?
I used v_shot in stead of g_shot.
Kinda Rusty But
check your bounding box's minimum? could be the min_z is 0 not -24.
I solved the shooting vector by changing Wiz_Start_Fast statements :
missile.nextthink = time + 0.6;
0.6 and 0.8 into the same counts.
And in Wiz_FastFire
dst = self.enemy.origin - 13*self.movedir;
dst = self.enemy.origin;
The two launch lasers come from both sides to the player without crossing.
Another thing is wondering me. While working on the Chasm_Rift models I keep the skin texture of 64x960. This odd format makes me play the mod only in Quakespasm. Fitzquake and other engines just won't start.
What would be the easiest way to convert this skin 64 x 960 to a more commen format?
Something with UV filters, I tried Noesis but I can't find a way to get to the skinfile.
AFAIK there is no limit on skin width. If that's the case, the easiest way is to just swap U and V. Here's
a quick'n'dirty script that should do the job. Make sure you test everything though, as it doesn't take stuff like on-seam offset into account at all.
It's also possible to move UVs around arbitrarily, then just re-project the skin texture, but it would be somewhat tricky to keep the pixels intact.
My computer is incompatible with the program.
I could try yo use it in Python, but Python doesn't like me.P:
Yes, thanks chedap.
That was just the thing I was looking for!
now I have my skinfile from :
height=960 x width=64
height=64 x width = 960.
If I'm not mistaken the maximum height = 300, the size of the width isn't that important I'm told.
When I make a try-out of the resized skins in Fitzquake085 it just shuts down. Maybe Mark V will do, but I was wondering how to reorder the skinfile back to a commen quake format.
Well yeah, that's what I said it'd do: switch width and height. Weird that it shuts down. I know Nehahra had 1500px+ width skins, but that's Nehahra.
I'll try things out myself, give me a couple of days. Previously I just tested if it loaded in QME.
First skinfile I know is 300x200. Later on it changed to other formats as engines become more advanced, but it seems to be a prior limit.
I know there is a way to hussle with the UV map, but I never succeeded in doing so.
Probably Something Else
So first off, h_gross.mdl is reported as invalid by most programs (regular Quakespasm, QME 3.0, Blender importer). The version is reported as 'RAPO' instead of 'IDPO' though that tells me little. Curiously, it opens fine in QME 3.1, but re-saving it doesn't fix the issue. It's probably easier for you to re-convert it properly than for me to poke blindly at it.
Now then, h_gross aside (replaced it with another h_grunt), the good news is that this actually runs just fine in regular Quakespasm, QSS, FTE, BJP and even in WinQuake
. On DOSQuake it won't run on account of 200 height limit (fan.mdl skin is 616x252 and can't be packed tighter, short of remaking the thing from scratch).
So I don't think the issue's in the skins (or in my script).
FitzQuake and GLQuake both crash though. Well, the map does, can load to vanilla maps fine. Maybe there's some other weird limit it's hitting - I wouldn't know. Try a simpler map.
A slightly safer version
of the script that now accepts entire folders. Still barebones, ignores on-seam etc - I went through the models and none of them seem negatively affected (for comparison try putting fan.mdl through this and check the resulting UVs).
So I don't think the issue's in the skins
I can't see another reason.
The error of the h_gross comes in like a bug somewhere.
If I would have simply copied it I could see a reason for a hidden flag that gives that recall.
But I made the h_model myself, just like all the others.
When I have the one last stand frame of an entity and I clipp off all, except the head, where can be the flag that's says I come from Hexen2?
Another thing, the fan model I made myself so it's easy to clip that skin file back to 200x300.
I think it are that irratic 960 x 64 seize that make account.
Sometimes, i make some edits in a model and quakespasm-spiked refuses to load it, and shows that message about it being in a hexen2 format.
To solve this, open the model in QME, go to "Utilities/Remove Dangling Vertices" and "Utilities/Remove Degenerate Triangles". Save the model.
It works for me.
- As of devkit2.27, it runs on DarkPlaces, DirectQ, FTE, QSS and QbismSuper8
- If I swap UV, it also runs on MarkV(DX), Quakespasm, TyrQuake(GL/SW), vkQuake and WinQuake
- If I then also crush the height of the fan skins, it runs on DOSQuake
- If I then replace joker.mdl, it also runs in FitzQuake and MarkV(SW)
- If I then replace fense.mdl, it also finally runs in GLQuake
- If I then recompile with 256x128 sky2, it will show up in DarkPlaces
I haven't done anything with h_gross (skin height 512), and it still runs even in DOSQuake. That means it's possibly not the only one waiting to cause problems.
joker.mdl has artifacts in QS
and in vkQ
. Looks fine in other ports. Probably some broken geometry.
fense.mdl just has too many vertices.
Sky textures have a specific size and both halves are supposed to tile independently.
Odd Lighting Artifacts In Darkplaces
I'm currently trying to bring a photogrametric model into the darkplaces engine.
Cleaning and reducing the mesh and baking it's textures within blender seems to work fine.
Yet, within the darkplaces engine the model shows odd lighting artifacts, some triangles are darkee or lighter than others.
I am exporting the mesh from Blender into .md3 and compiling the map via q3map2.
Got no clue what causes the problem, but i also have to admit i'm certainly lacking some modelling knowledge.
I have checked the normals of the faces, those seem all to be right, also the faces are smoothshaded within blender.
Any clues what i am missing here?
Here are some screenshots, the one at the bottom shows the model within a testmap: https://imgur.com/a/NqrWeRA
1) Select all faces;
2) Shift + N to recalculate normals outside;
3) export again to see if it helps;
Was My Thirst Thought Too
also the first thing i tried.
Did it again, just to be sure, unfortunately without success.
All normals point correctly outwards within Blender too.
I aslo tried to export the model as .ase, compiling the map with this one yields the same result.
Currently i am trying to clean up the mehs some more, but apart from that i'm out of ideas...
Mark some hard edges on all of the statue base, as they shouldn't be smooth.
Set the normals to auto-smooth under vertex data and set the auto smooth angle to 180 degrees.
Dark places must need lightmap data for the model and you may need a light unwrap that is different from your diffuse UV data. There can be no overlapping faces in the light unwrap. Use a smart UV project function to quickly do this. Same situation as baking lighting in UE4
Got A Trail Now
Set the normals to auto-smooth: check
smooth angle 180 degrees: check
no overlapping faces in the uv-map: check
The problem seems indeed to be the lightmapping, or rather the lack of it.
Q3map2 is refusing to lightmap the model but rather vertex-light it, no matter what i have tried.
This is what causes the wrong shading, as far as i can tell.
I have my .shader properly set up with the parameter q3map_forceMeta in the material, i have set the spawnflag 4, which should also force meta an thereof lightmap the model, i even set -novertex in the lightstage.
Yet q3map2 does not comply.
Tried other handmade models too, they get lightmapped just fine.
Is there a upper limit of polys/vertices a model may have for q3map2 to lightmap it?
Currently the model has 2145 verts and 4286 faces.
I've opened your model (from the other thread), and the actual UV islands
don't match the seams shown here
. Instead they just about perfectly match the shading problems you're having.
At the risk of stating the obvious, just marking edges as seams is not enough - you should then unwrap, pack, re-project the texture, change the material and remove the old UV map.
Every Information Helps
as for me nothing in that regard is obvious yet ^^'
I tried your tipps and those from above to the best of my abilities, yet the problem seems to become worse.
I have simplified the mesh some more, deleted all previous materials, textures and uv maps, marked sharp edges, did the seams from the beginning, unwrapped them, reprojected the texture, created a second uv-map for the lightmap, packed it.
In the shader i am using the q3map_forcemeta, q3map_nonplanar and q3map_shadeangle statements, shadeangle is at 45d.
Spawnflags 4, in the compilersettings -trianglecheck is set.
To no avail.
It is likely that i get the packing part wrong / the part with the separate lightmap uv's.
Especialy when it comes to how and if q3map2 / darkplaces reference them.
I uploaded the actual .blend file:
I'll look into this once I have some time to figure out q3map. Right away though, your sharp edges currently have no effect since they're being overwritten by custom normals. Click "clear custom split normals" under geometry data.
I'm not at all sure DP or the compiler make use of secondary lightmap UVs. But if they did, using Blender's "lightmap pack" doesn't seem appropriate in this case (and you'd need much more padding anyway). We want lighting to spill over geometry, but don't want it to bleed between UV islands. This means we want less islands, not more. Not sure lightmap-specific UVs are even needed here.
While I'm figuring things out, what are you using for import/export? I've only found .md3 exporter for Blender 2.7x, you're clearly on 2.8x. When I imported your previous model, it had edge splits at every seam - not yet sure if import, export, format or modelling problem (if it is a problem).
The .md3 exporter i use seems to be a 2.78 exporter retrofitted for 2.8.
Found it via a big searchmachine.
I also tried an .ase exporter, yields exactly the same results.
Your tipp with "clear custom split normals" did help somewhat:
I also set the margin for the uv islands higher and deleted the second uvmap.
I've imported the compiled map, and it turned out that the model gets split into parts
at bsp stage. I then recompiled without the "-meta" flag and got this result
. Seems alright.
I don't know what other consequences omitting "-meta" has, or if there's a more elegant solution. It seems that the problem is unrelated to UVs or model specifics though.
Never figured out how to get a good lightmap resolution, does it have to be defined per-material?
A very interesting discovery!
Afaik -meta is considered a "must" switch since the highdays of q3 mapping.
Regarding to q3map2 itself -meta "Combines adjacent triangles of the same texture to surfaces", which seems to improve performance because of saving triangles.
As for lightmapping models, meta also seems to be considered a must, as for example spawnflag 4 proves, which forces meta on a model.
Here is what the Radiant has to say about it:
"FORCEMETA : Toggles on q3map_forceMeta for lightmapped models. Converts model triangles to bsp metasurfaces."
Not sure if it really still is a "must", but there must be a good reason why it is still considered so, apart from saving a few hundred triangles.
There are two new switches in that latest version of q3map2 (2.5.17.n) included with NetRadiant:
Adequate score for adding triangles to meta surfaces
Good score for adding triangles to meta surfaces
No clue how those are properly used though, i.e. what the baseline of that score is or should be or how it is calculated, but those could lead to the desired solution then, to get the model not as "chopped" up by -meta.
To get a good lightmap resolution, q3map2 has a few options to offer:
Per material settings (set in the .shader),
per entity settings (set via entity/func_group),
per world settings (set in the worldspawn),
and finally per general setting, via compile switches (most important here is the -samplesize switch, wich has to be set both in the bsp and light stage to work).
I always use the latter to set a higher resolution baseline and fine tweak from there.
My standard switches for the light stage are set as follows:
bsp -meta -samplesize 4
light -samplesize 4 -thresh 0.1 -deluxe -samples 4 -filter
The -fast switches just make no sense to use for me anymore, as even settings that where considered "ultra" in 2005 are just as fast to compile as testsettings back then, on nowadays machines.
Ah, I was missing the bsp -samplesize.
A brute force workaround then is to just use "-samplesize 1". Not perfect but getting there
. Would give your hardware a chance to sweat a bit, too.
Well, I'm not entirely serious, preferrably there'd be a way to keep the slivers together instead. I'll try some things, but at this point I know less than you do.
Here -samplesize 1 didnt yield the same result:
I now played around a bit more with the -metaadequatescore
switches and found out that they indeed change how q3map2 breaks up the model.
Q3map2 also pointed to the source file surface_meta.c, where i found out the baseline values seem to be as follows:
DEFAULT_ADEQUATE_SCORE = 110000
DEFAULT_GOOD_SCORE = 120200
PERFECT_SCORE = 131200
Yet i have yielded no satisfying results and have no idea how to properly (ab)use those switches.
Using "_lightmapscale" "0.25" entitiy attribute gives the same result as samplesize 1, except locally. Here's a result
of a basic compile with the following:
-bsp -meta -samplesize 4
-light -samplesize 4 -samples 4 -lightmapsize 1024 -filter
I also got it to split the models less
, using these:
-bsp -meta -samplesize 4 -metagoodscore 50000 -mv 30000 -mi 30000
-light -samplesize 4 -samples 4 -lightmapsize 1024 -filter
(no _lightmapscale in entity this time)
The problem is that I can't see a way to finely control this, basically it just randomly picks a direction and compares normals. Cylinders always look bad. And it seems like the very best case we can hope to achieve would just be the exact copy of compiling without "-meta".
Not sure why you couldn't get the result with "-samplesize 1". Here's the model+texture
I'm using (texture reprojected from the low-res one in the .pk3).
Compiling without "-filter" noticeably improves the seams on cylinders, but makes the rest of the lighting worse.
I'm throwing in the towel for now. At least this hasn't been entirely fruitless. Maybe people with q3 experience could tell more.
Thanks for the help, it is very much appreciated!
I will move on too as this is offtopic now, strictly speaking.
Now i got a got lead and will eventually figure it out.
really cool project! photogrammetry with q3map2 and darkplaces is something I've wanted to experiment with for a while now.
quick question, why are you lightmapping this model? It's so dense why not just vertex light it? your results will be very good and cause fewer headaches.
you *can* lightmap something like this, but it can be a pain, as you've found. this will get worse in an actual scene with more complex lighting (like bounce).
don't underestimate the power of vertex lighting ;)
a test: https://imgur.com/a/e2lIirT
@kp, from the other thread
, apparently the lightmapping is forced on anything that exceeds 1024 verts. That is, as long as "-meta" switch is on, which is the recommendation everywhere I looked.
1024 per surface would be alright actually, but contrary to that post, in practice bsp seemed to split the model into max 128 vert chunks here
(while in the source
default maxLMSurfaceVerts is 64?)
@wakey, if you do end up using vertex lighting, you might want to at least subdivide the top of the foundation a bit, so the lighting isn't stretched.
Seems I Underestimated
vertex lighting after all.
Very beautiful screenshots @killpixel!
How did you get to be just vertexlit?
Leaving out -meta alltogether?
In general i would have no problem with leaving the -meta stage out, if i understood what the drawbacks of that actualy might be.
My guess is that -meta in reality might only be relevant for true idtech3 games, as those have a actual problem with surfaces exceeding 1024 verts, most notably Q3A itself.
With darkplaces on the contrary -meta seems to mess things up, not only for the models, but i also noticed some brushsurfaces not beeing properly lit by rt-lights when using -meta.
@chedap: thanks for the tipp, will do that.
Shedding Some Light
the test I posted is using -meta
. from the wiki (which is probably pretty outdated):
At one time, there was a clear definition as to what, exactly, the -meta switch did. Now, it has become the "magic" switch that is required for most of Q3Map2's advanced features. Always -meta, and always -v.
I was under the impression it grouped neighboring triangles into larger lightmap islands because that worked better for things like phong shaded terrain.
Anyway, I forced vertex lighting on the model with a simple q3 shader script:
prevents lightmap generation, and rgbGen vertex
tells the texture to grab the vertex data for shading.
I recommend learning more about q3 shaders
. they're quite powerful, even with DP's limited implementation.
chedap is right, you should add some loops to the foundation and base if you're going the vertex lit route.
also, I'd avoid clipmodel
) for a model this detailed - use a clip brush instead.
Darn I'm Stupid
could have thought of surfaceparm nolightmap<q/> myself, as i am familiar with q3 shaders ^^'
Anyhow, the model now looks as intented:
Thank you a lot, killpixel & chedap!
In return i could answer any questions regarding photogrammetry, if there are any.
good luck with the project, looking forward to seeing more of it
who made this https://www.youtube.com/watch?v=SPWhp3KDxqM
shambler model. Is that Chillo's ??
the hands look diff. I just wanna give credit to my video.
Speaking Of Shambler