Zircon Engine - a "DarkPlaces Mark V" project mod for Quake

July 11: Animated GIF to .shader (Download: Zircon Beta #59)

Mountain Terrain 1: Download Q1SP + .MAP sources + .shaders + .ase grass/shrub models

I discovered this page: Karsiori.itch.io

Pictured: Trying to get this area to have some "character".

Zircon supports animated gifs for the playvideo command. However, I want the easy ability to use these type animated gifs in a map as textures.

So I'll be writing an animated gif to shader console command that will turn each frame into a separate .tga image and write out an appropriate shader.

I could manually convert a couple of them, but this sounds like something a machine would be great at --- I prefer to write the code and let machines do what they do best.

July 10: Decal Projection ✅ (Download: Zircon Beta #59)

Mountain Terrain 1: Download Q1SP + .MAP sources + .shaders + .ase grass/shrub models

The decal flickering fix is a single setting mod_q3shader_default_polygonoffset "-14" which will likely become the default in the next Zircon.

Changing this while a map is running won't take effect unless a renderer restart occurs. Pressing ALT-ENTER is one way to restart the renderer immediately.

// Requires render restart to take immediate effect if a map is already started
// Pressing ALT-ENTER will restart the renderer, so that's one way ...

mod_q3shader_default_polygonoffset "-14"

Technical note: "r_glsl_restart" is not enough of a restart. Needs to be a full renderer restart ("r_restart").

July 10: Decal Projection ✅

Finally got decal projection working which is huge deal for some of my experiments.

Decal projection will -- in theory -- allow some effects in a map with minimal effort ... a texture can simply be projected onto the terrain. The theory is this might be able to be used to enhance terrain appearance in certain area (sand, paths, etc.) without any texturing by projecting the effect on the area.

Pictured: The splatter decal never flickers or z-fights at any angle.

The settings I used --- some of these are obviously not related.

Too successfully use: Must start engine and set these settings first before loading textures or map. Setting these after loading the map, they do not take effect immediately or they only occur on map load -- the short version is it will fail.

mod_bsp_portalize "1"
mod_obj_orientation "0"
mod_q1bsp_polygoncollisions "1"
mod_q1bsp_zero_hullsize_cutoff "8.03125"
mod_q3shader_default_polygonoffset "-14"
mod_q3shader_force_terrain_alphaflag "1"
r_bloom_colorscale "1.5"
r_bloom_colorsubtract "0.125"
r_depthfirst "1"
r_framedatasize "2"
r_picmipsprites "0"
r_polygonoffset_decals_offset "-28"
r_polygonoffset_submodel_offset "0"
r_shadow_glossexact "1"
r_shadow_realtime_dlight_shadows "0"
r_shadow_realtime_world_importlightentitiesfrommap "0"
r_shadow_realtime_world_lightmaps "1"
r_shadow_shadowmapping "0"
r_subdivisions_tolerance "3"
r_textbrightness "0.2"
r_textcontrast "0.8"

Had to perform some deep mining of Xonotic's countless cvars and .cfgs.

July 9: Recent Failed Experiments (Download: Zircon Beta #59)

Mountain Terrain 1: Download Q1SP + .MAP sources + .shaders + .ase grass/shrub models

The last few days most of my experiments have had mixed results or failed. Failed experiments always yield knowledge and some nice things are coming down the pipeline.

Pictured: A "failed" experiment. One of many. Crashing against the rocks is the "no fun" part of research. That is decal projection in a Quake 3 format map and no matter what settings are used, it always z-fights.

Correction: Quake 1.5 HD is using Zircon Alpha 60 as the engine, not Zircon Beta. The author of Quake 1.5 HD has helped provide information on things that Zircon Beta does differently (or worse) than Zircon Alpha. The great thing is these are very nuanced bug reports and not typically the type I personally would notice and maybe not even most users would notice, but they are definitely behavior differences (partial model transparency, RT light behaviors, retexturing classic sky ..).

Some interesting mini-projects are coming within the next week.

July 6: "_odds_scale" worldspawn key

q3map2 compiler in downloads section with "_odds_scale" worldspawn key -- a key that globally modifies q3map_surfacemodel odds globally for all shaders in map. Allows quickly reducing or increasing random model placements everywhere setting a single value -- as opposed to editing several shaders manually.

Pictured: Tried "_odds_scale" "0.25" to see what far less trees/brush might look like.

[Or worse -- copying the shader text and renaming them -- then changing the values and then replacing the textures in a map with the new shader.]

July 5: Final Tree Test

July 4: q3map_surfaceModelCollide

There is a q3map2 in the downloads section with q3map_surfaceModelCollide [render model] [collision model] support with source code.

Pictured: q3map_surfaceModelCollide is what makes the above possible with "deformVertexes autosprite2" for the render model (a model with a big top and pole bottom unsuitable for collision) and a thin pole model as the collision model. All instances where the render model occurs, the collision model occurs with the same angles/scale. The collision model texture has surfaceparm nodraw and q3map_clipModel -- the q3map_clipModel forces it as a solid during map compile.

July 4: Collision Plan B

Mountain Terrain 1: Download Q1SP + .MAP sources + .shaders + .ase grass/shrub models

The bad news for colliding masked "autosprite2" where much of the surface is see through is that q3map2 will not allow me to make an .ase (produced from a .bsp via a q3map2 command line) with 2 brushes -- one for rendering and one for collision. I can make it, but it renders incredibly weirdly and looks terrible.

The good news is that I had a backup plan before attempting this and it worked perfectly. Added new q3map_surfaceModelCollide to my custom q3map2, compiled and got the result I sought immediately using a shader for testing that looked like:

q3map_surfaceModelCollide  models/outdoors/_autosprite3.ase maps/_collide_2_2_32.ase 		38		   0.025  8    16    1 122 1

The first parameter is the model to render AUTOSPRITE2 (models/outdoors/_autosprite3.ase) and the second parameter is the COLLISION MODEL (maps/_collide_2_2_32.ase) -- a second model that blocks movement. The collision model gets the same scale and angles and everything else and is processed after the render model.

July 3: Too Many Trees Test2

Test to see if these q3map2 (Q3 map format) "autosprite2" trees shadow well. And see how well they collide.

They shadow well. There is the "surfaceparm alphashadow" .shader option -- however these trees are mask textures and mostly see through and alphashadow does not give them much of a shadow at all (if that is used, and it is not being used here).

Collision .. putting q3map_clipModel in the texture shader will cause it collide ... however this is masked texture that is mostly see through.

Side Note that "q3map_clipModel" collision is generated during map compile time (the "q3map_" is the give away). DarkPlaces is great at reloading textures with "r_restart" but "r_restart" will not obviously recompile a map and so "q3map_clipModel" not a shader parameter that be tested inside the engine -- a map recompile must be done first.

It collides poorly and a command in DarkPlaces to see the surfaces is "r_showsurfaces 1" which looks like this:

r_showsurfaces 1 reveals the surfaces and as one might imagine, with collision we cannot pass through areas that visually we would expect to be able to walk through.

There are 2 options available to resolve this .. either make the .ase have a 2nd texture that represents the collision part and is smaller or add a q3map2 modification allowing an extra "collision model" to be specified. The simpler method is to option is modify the .ase, which is going to be the first option tried.

July 3: Quake 1.5 HD Switches To Zircon

The author of Quake 1.5 HD has switched to distributing Zircon Beta engine instead of DarkPlaces Classic.

freddiehimself contacted me and said "The game on Zircon is now a completely new experience. I have already taken care of publishing the Zircon version of it (beta 3)."

"very impressed, especially regarding lighting and shadows" He also reported 2 behavior differences to investigate.

July 3: Too Many Trees Test (Download: Zircon Beta #59 Win64/Linux)

I did a test with far too many trees to stress test this. Without video capture software running, was in the 500-700 frames per second range a lot occasionally going to about half that. I don't really know how many trees there are, but it is an unreasonable number.

Pictured: If it can render a unreasonably high number of trees well with very good frames per second, this is a good test result.

These are "autosprite2" trees -- a lightly documented q3map2 feature that had a caveat that is not in any documentation (brush must be power of 2 with one side double size and power of 2) that fortunately I found the caveat eventually because it simply was not working time after time.

Had to make a .bsp with a brush made to above specification and convert it to .ase and this was a chore that will be a simple Zircon command in Zircon Beta Release #60 to make one out of thin air with a specified texture on it.

July 2: Vegetation/Trees

Zircon Beta Release #60 will have a "vegetationmake models/outdoors/bush55.png" that creates a .ase for misc_model and q3map_surfaceModel named "models/outdoors/bush55.ase" for such a command line.

Note: Discovered 90 degree elevation light angle is a bad (straight down) . That is why plants on flat surfaces are dark and ones on slopes are well lit. Mystery solved.

More tests ...

This helps turn images like Opengameart.org into .ase for inclusion a map rapidly and the "vegetationmake" command does path aware autocompletion.

These tests are good but not quite perfect, but definitely heading in the correct direction. Questions remain about the lighting and I also noticed that specifying multiple q3map_surfaceModels -- they can plant one or more models in more or less the same place. Want to check autosprite -- although generally I prefer non-autosprite. (Autosprite always faces you -- autosprites are great for certain textures like flares and sometimes they are used on vegetation.)

July 1: q3map_surfaceEntity

A q3map2 compiler that can do surface entities is in the file downloads section. The readme in the download has details.

June 30: q3map_surfaceentity

q3map_surfacemodel is nice, but for level of detail entities -- at the current time I need entities. And I do not want to plant trees myself, I want q3map2.exe (the Quake 3 map compiler) to do this for me.

q3map_surfaceentity is not a feature of q3map2 -- I will be seeing if I can do that today. In my head, the thought is allowing it to specify a text file which it reads and then replace "$ORIGIN_X$" with the x origin, "$ORIGIN_Y$" .. etc. Including angles and scale. Then appending that to the entities section of the .bsp.

June 29: Level Of Detail

Wrote a CSQC based level of detail mod as a test candidate for terrain maps. I have the distance cutoffs as automatically created cvars by the mod.

1. Level of Detail 0 = Red = Close = Higher polygon model (models/outdoors/tree03_lod_0.md3)
2. Level of Detail 1 = Green = Medium = Moderate polygon model (models/outdoors/tree03_lod_1.md3)
3. Level of Detail 2 = Blue = Far = Lowest polygon model (models/outdoors/tree03_lod_2.md3)

Uses a method almost identical to the method used in Xonotic except a bit more streamlined.

Intend to make a terrain map using this as a demonstration and provide the CSQC / QuakeC source code.

Technical notes: Considering putting this type of feature into the engine, and perhaps it eventually will get there ... but I want to think about that more -- there are some aspects of this that are "wrong" for the engine to do -- for one the method I use requires 3 model precache slots -- also I don't want to write a new network protocol right now nor extend DarkPlaces Protocol 7. With QuakeC and CSQC, there is network communications and I use that for this and the method I use should have very light traffic and works well with DPP7 baseline compression.

June 27: Another Test

A quick and dirty Blender decimate .. imperfect but good enough for testing purposes. Lighting still not quite "right". Other small issues.

June 27: Tree Test

Created a shader for models/outdoors/tree_bark2 (below). Results are "on-track", but there is more to do.

The trees and such were added by q3map2 during map compile using q3map_surfacemodel. One of the tree models has a leaves texture and a bark texture. q3map_clipmodel makes the bark collide with the player (solid). So most of the surface models are non-solid, but the trees and some of the brush are solid.

I don't want to be manually placing trees, that is not a fun activity.

models/outdoors/tree_bark2
{
	q3map_clipModel
	{
		map models/outdoors/tree_bark2.tga
		alphaFunc GT0
		rgbGen vertex
	}
}

Some things that need improvement is the tree shadowing I would like to be less heavy (and for the brush too). And these trees are rather low poly, but I would like to find some that about 50% or 25% that have an equivalent appearance.

June 27: About Large Maps

I've done some experiments lately that have not paid off yet .. that is the crash against the rocks part of "Research and Development" .. yesterday I was surprised by this map ..

Pictured: qs_bigmap (download) for Quake Sandbox (an Open Arena fork with way more capabilities and can load larger maps and saves the config to the actual game install folder too instead of some semi-random c:\Users\MyName\Saved Documents\Roaming\SomethingElse folder).

This map is astonishingly large for a Quake 3 map, the author Hypernoire told me that it required modifications to the Q3MAP2 compiler. This map does load in Zircon easy in a folder that I have Open Arena inside my Quake 1 folder, but the context looks better in the intended engine so that was used for the above pic.

When I loaded the map, I walked an eternity to try to find the edge of the map only to find there was a valley when I approached a line. This map is very, very large.

In a few days, some of the experiments I haven't completed yet might yield results.

This is not exactly what I want to do, nor how I want to do it .. but part of it on the right track. I have been working through some Xonotic QuakeC and the DarkPlaces source code to try determine the right way to be able to heavily customize the appearance of a model. In the above, I am using "framemap" -- a Q3 shader modification of "animmap" in Zircon to support buttons changing texture ... however .. wrong field and wrong method for doing this ... DarkPlaces has a "playerskin" feature ...

June 25: Footsteps/Brush Plant

Eventually, I could see 2 things that quickly come to mind.

1. In other games, going through brush may disturb them. This could be done here in QuakeC by making an actual real entity of a weed and giving it a touch function that changes the model from "models/outdoors/brush02.md3" to "models/outdoors/brush02_sway.md3" for a certain period of time. The models in the Mountain Terrain 1 map are .ase -- this is a text file that can be made from a .bsp using the q3map2 compiler. These .ase files are not a known run-time format for DarkPlaces, the free model editor Noesis can easily convert .ase to .md3 or .obj which DarkPlaces can load.
2. And once you have terrain and brush/weeds, it would feel better to have some terrain footstep sounds when going through the weeds. For the texture that has weeds, in the .shader set "surfaceparm dust" and in QuakeC during Player_PreThink add some footsteps QuakeC that checks surface flags for the player. Blood Omnicide DarkPlaces (a slightly different version by a regular contributor to DarkPlaces) had some surface flags shader engine modifications that I didn't understand the benefit of in the past -- I will have to look at that again and see if it somehow provided ability to customize surface flags.

The short version -- both are possible using QuakeC + mapping techniques.

Quake 3 .map V. Quake 1 map

They are the same .map text format (so is Half-Life by the way). I copy and paste brushes from a Quake 1 map to the Quake 3 map all the time. I must re-texture the brush because Q3 does not do .WADs, so I applied textures/floor_dark_slate.tga to the brushes of the teleporter because the Q3 map compiler does not know what "COP1_1" is (COP1_1 is the texture on the DM6 teleporter from id1.wad)

Pictured: The teleporter isn't similar to the DM6 teleporter. It was pasted from DM6.MAP complete with the "light" from the Quake map source release into Mountain Terrain 1.

Note that you can take brushes from Quake 3 and put them in Quake 1 map. However, this is the harder way to go -- Quake 3 brushes have few rules other than don't do concave. As an example in Quake 3, you can make brushes less than 1 unit wide -- you might actually want to do this for a wire or cable (in J.A.C.K. use CTRL-M to scale a brush by percentage is the easiest way). Brushes that are ok for Quake 3 are sometimes invalid brushes for Quake 1 map format.

Mountain Terrain Q1SP/.MAP

The playable standalone Mountain Terrain 1 map (put pk3 in c:\quake\id1 folder, start Zircon, type "map mountainbaker1") has the map source code in .MAP (TrenchBroom) and .JMF (JACK). And all the .shader files and several .ase and .md3 models (see models/outdoors/grass02.ase or models/outdoors/corn02.ase) which are terrain models for use in a .shader file (q3map_surfacemodel places them).

(Put .pk3 in id1, start Zircon and start the map. Pure Q1SP with no -game or anything.)

Pictured: The map has under 10 monsters and an exit. Its main purpose is as a tutorial showing how various effects can be achieved like vegetation and terrain blending. Frame rate --> HIGH. The entire map is under 46,000 triangles even with the vegetation (the Quake start map is 15,818 triangles).

Pictured: Some of the weeds sway.

Pictured: The mountains seen from the island are not skybox pictures, they are part of the map.

Pictured: Notice the dog running around (bottom right). This is the view from higher up.

Mountain Terrain Test 1 (Q1SP) illustrates use of techniques for vegetation and terrain blending and other methods for use in J.A.C.K. or TrenchBroom using the Quake 3 map format to make maps for Quake 1 for use with the Zircon Engine or DarkPlaces.

Pictured: The top of the largest mountain has a rather large area on top.