ℹ️ If you have trouble registering or do not receive a verification e-mail, please ask for help in chat.
⚠️ We have removed underscores from user names (know more), if you have trouble to log in and your username featured an underscore, please retry without underscore.
You know, netradiant and q3map2 are very old, they do not compete with newer solutions, but it's not a problem for many enthusiasts if it works for them? Even if it's dated, it's not a problem for many enthusiasts if they can do something they can be proud of, if they can do it without frustration. The main problem is not having plenty of shiny functionalities, the main problem is when basic functionalities are hard to deal with.
1. Source versioning
Netradiant renumbers all changes entities and patches every time it saves the map, so every minor change leads to thousands of line changes. My map cutter can denumber the map files and I'm using it every time before commit. A very good thing would be to have an option in netradiant to not number the entities by default. It's good to keep a way to number entities to be able to debug the file by hand (mapping the vim way) while reading a compilation log.
By the way, my map cutter knows how to renumber a map. Due to legacy stuff, netradiant must keep the do not number the entities option deactivated by default (opt-out). By the way, it could be a per-game default setting (we can imagine that mappers for dæmon based game get a nice profile without needing to tweak it, while mappers for legacy games keep the legacy behavior, since they will already miss all the other enhancements).
To help managing source cleanly, the build process must be manageable by a dedicated build tool, and the build tool must allow out of tree compilation.
1. Build process
My pak mallet can handle the build of a complete pak including asset compression and map compilation, based on a per-file rule list it can auto update itself. I have many improvements to do but the basis are there.
2. Source based compilation
The mapper must be able to keep a clean source tree and must be able to compile and test his production against a clean environment. It means both dæmon, netradiant and q3map2 must be able to load any paks from any directory the mapper wants (pak dependency…), they must be able to load pk3dir, and q3map2 must be able to compile from a source dir to a build dir. The mapper must be able to never load his built map from the source dir (that way he is only testing final assets).
Dæmon already allows all of that. I have patches pending for q3map2 that allows arbitrary pakpath loading and out of tree compilation. It looks like netradiant knows how to load pk3dir (there was a something done) but it seems q3map2 still lacks this support.
Netradiant and q3map2 must have an option to not load user game data in pkg dir to not mess with foreign stuff.
Also, q3map2 must have an option to not rely on shaderlists and load all shaders since there will be explicit options to get a clean source tree.
The mapper must be able to load a map in netradiant from command line or using file association.
4. Fast and easy testing
This is now the major part, and all these ideas are doable. There is two axis: doing things fast, and integrating tools.
gimhael added a fallback lightgrid in dæmon (skipping lightgrid compilation saves a lot of time) and I have some pending changes to speed up the lightmap allocation process in q3map2.
Dæmon allows to send command to an existing instance and to set the camera in an arbitrary position (it still lacks the ability to set the angle in all directions), so, it could be possible to netradiant having the engine loaded in another window and having the camera in the engine following the netradiant camera.
Dæmon must be able to load a map without intermission and spawn entities, spawning floating in the middle of the map, and Dæmon must be able to load a layout from a pk3[dir] (I read somewhere that tremulous was able to use alternate layout in pk3, is it still true for Dæmon and is the default layout can be an external file in the pk3?), so the mapper will not have to put the structures entities in the map but can layout his map in game directly. It also allows to modify the default layout without having to alter the bsp.
Netradiant must allow to define a box with the camera in center of the box (the volume of the box must be modifiable by the user). This box coordinates and size must be exportable by netradiant (in a temporary file for example), so q3map2 can read it. q3map2 must be able to cut out everything which is outside of this box and build valid edges with a visible recognizable texture on box edges to prevent leaking. This functionality will allow the mapper to render only a part of the map. It's very important to save hours when the mapper tests his lightmaps.
For example, this whole room takes only 43s to render with 5 radiosity bounces (but I spent hours to manually cut out everything outside):
This very big room room takes only 43s to render, But the whole map takes about 43min to render… So, with that option the mapper will be able to test his rendering in less than minutes! The mapper will be able to test his rendering room per room!
There was also some work done on dæmon's side to allow engine embedding. It can allow the engine to be embedded in a netradiant Window.
Imagine : the mapper have the mapping editor window, the basic 3D renderer of netradiant to edit stuff, and the engine window. Clicking one button will compile the current room, send the devmap, noclip and setviewpos commands to the engine so the engine reload the map in the current room. The mapper can see the rendering in game, layout his map (and save the ingame layout from a netradiant button) etc. If the mapper ticks a checkbox, the compilation only compiles the current room (everything inside the box that follow his camera) and reloads the current room in game in less than a minute!
I'm thinking about something like that:
See this screenshot for example (taken from this thread by krtv`):
As you see, the shadow must not be casted on the lamp.
Another good thing I think about: the renderer can also read the q3map_surfacelight shader options to cast shadows using the texture as shadow casting origin. I know there is an option in q3map2 to export light entities in the bsp too (by the way it was disabled by default in tremulous build profile, I don't know why, and I don't know how these exported light entities can be used or not, and I don't know if the surfacelights are exported as small light entities (since it works as subdivision in the lightmapping process), it can be good if it can avoid to read the shaders to cast shadows…).
Edit: As Calinou said on IRC:
<Calinou> why not just avoid casting shadows on glow map?
Whatever the solution, not casting shadow on things that looks like a lamp would be good, there is probably many ways to do that.
Since Unvanquished is a free and open source game and since Dæmon is a free and open source game engine, Unvanquished must be hackable from the start. The Unvanquished game must become a nice platform to map and mod, people must be able to enjoy themselves contributing textures or sounds and making maps, being proud of what they do with Unvanquished and Dæmon. Many free software people don't really care if some tools are aged if they can be proud of what they do with. I don't care myself if some tools are old, but once beta reached, people must not have to sacrifice a redhead goat an evening of full moon under the lights of torches while a choir of 40 virgins sing the verses of the Book of Dave.
illwieckz wrote:Since Unvanquished is a free and open source game and since Dæmon is a free and open source game engine, Unvanquished must be hackable from the start. The Unvanquished game must become a nice platform to map and mod, people must be able to enjoy themselves contributing textures or sounds and making maps, being proud of what they do with Unvanquished and Dæmon. Many free software people don't really care if some tools are aged if they can be proud of what they do with. I don't care myself if some tools are old, but once beta reached, people must not have to sacrifice a redhead goat an evening of full moon under the lights of torches while a choir of 40 virgins sing the verses of the Book of Dave.
neumond's netradiant branch (DEPS radiant support):
neumond's GtkRadiant branch (pk3dir q3map2 support):
This branch was restored from a now-deleted repository. Hopefully a PR was made (see TTimo/GtkRadiant #260 )and even if this PR was closed and never merged, GitHub allows to fetch pull requests.
Just for a memo I note there how to fetch a PR from a repo (here, upstream) and upload it as branch (here, neumond) to another repo (here, origin):
Code: Select all
git remote add upstream firstname.lastname@example.org:TTimo/GtkRadiant.git
git fetch upstream pull/260/head:neumond
git push --set-upstream origin neumond
[Edit: in fact there was already pk3dir support in q3map2 from netradiant, it was just broken on my own setup ! ]
- unvanquished game support,
- out of tree compilation,
- fast lightmap allocation,
- many bugfixes like an ugly one that deleted the lightmap shader on minimap generation!
The last one remaining is the navmesh code, but it needs some talks and some improvement.
Thanks to TimePath
Who is online
Users browsing this forum: No registered users and 5 guests