My dreams for netradiant/q3map2/what you want.

Request new features or present your ideas.
User avatar
illwieckz
Project Head
Posts: 465
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

My dreams for netradiant/q3map2/what you want.

Postby illwieckz » Sun Feb 21, 2016 9:38 pm UTC

This my ideas to avoid the more frustration while mapping for dæmon based games. Dæmon is an open source engine, so Unvanquished is not only a game, it's also fun stuff to hack with. So, we must offer a nice mapping experience to see people having fun to hack with the dæmon engine and Unvanquished.

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.

3. Usability

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):

Image

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:

Image
Last edited by illwieckz on Tue Feb 06, 2018 2:05 am UTC, edited 1 time in total.
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
illwieckz
Project Head
Posts: 465
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: My dreams for netradiant/q3map2/what you want.

Postby illwieckz » Wed Feb 24, 2016 12:02 pm UTC

About (real time) lighting and textures, I have the idea of another kind of texture, there is already diffuses, normal, glow etc. We need some « do not shadow » textures. I mean, since shadow are cast over surfacelights (or just textures that looks like a lamp) , we need one mask to force the real time shadows to not be drawn on there. It can be a color/alpha channel.

See this screenshot for example (taken from this thread by krtv`):

Image

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.
Last edited by illwieckz on Tue Mar 22, 2016 6:38 pm UTC, edited 1 time in total.
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
illwieckz
Project Head
Posts: 465
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: My dreams for netradiant/q3map2/what you want.

Postby illwieckz » Thu Feb 25, 2016 12:33 am UTC

Just a notice, having an asset toolchain capable of working with gitable source pk3dirs all the way down and capable of building any asset to the best format (texture and sound compression, map compilation, minimap and navmesh generation, etc.) is my own unofficial target for beta. Unvanquished must have for beta an asset toolchain handling all the good practices better, easier and faster than fast and dirty hacks. Once reached beta, Unvanquished must not need magical skill to contribute assets. So, it means all (current and upcoming) needed patches for q3map2 and netradiant to achieve that must be mainlined for beta, and I'm ok to stick on it. Also, it means all the tool we have (the legacy ones and the one I'm working on) must be able to convert, build and package the complete Unvanquished assets. :advgranger:

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. :granger:
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
lamefun
Tyrant
Posts: 368
Joined: Mon Jun 04, 2012 10:29 am UTC

Re: My dreams for netradiant/q3map2/what you want.

Postby lamefun » Thu Feb 25, 2016 9:14 am UTC

I think it would be much better if NetRadiant died and maps were made using Blender. This way, by learning the basics of mapping people would learn the basics of a proper modelling program, where you have a nearly unlimited potential for growth. I mean, really, the Unvanquished maps look as if everything were made of squares! In Blender, you can use curve modifiers, bevel, subdivision, proportional editing, sculpting, etc. etc. etc. to make fluid, beautiful environments and not be limited to 90 degree angles.

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. :granger:


:thumbup: :thumbup: :thumbup: :thumbup: :thumbup: :thumbup:
User avatar
illwieckz
Project Head
Posts: 465
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: My dreams for netradiant/q3map2/what you want.

Postby illwieckz » Tue Mar 29, 2016 7:50 pm UTC

So, here is interesting stuff to merge in netradiant/q3map2.

neumond's netradiant branch (DEPS radiant support):
https://github.com/neumond/netradiant

neumond's GtkRadiant branch (pk3dir q3map2 support):
https://github.com/illwieckz/GtkRadiant/commits/neumond

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 git@github.com: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 ! :bsuit: ]
Last edited by illwieckz on Thu Apr 14, 2016 10:02 am UTC, edited 1 time in total.
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
illwieckz
Project Head
Posts: 465
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: My dreams for netradiant/q3map2/what you want.

Postby illwieckz » Thu Apr 14, 2016 7:24 am UTC

So almost all my commits for q3map2 were merged!

  • 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 :thumbup:
This comment is licensed under cc ​​by 4 and antecedent.
User avatar
Viech
Project Head
Posts: 2139
Joined: Fri Aug 03, 2012 11:50 pm UTC
Location: Berlin

Re: My dreams for netradiant/q3map2/what you want.

Postby Viech » Sat Apr 16, 2016 4:43 pm UTC

Good job! Navmesh generation in q3map2 would be nice indeed.
Responsible for: Arch Linux package & torrent distribution, Parpax (map), Chameleon (map texture editor), Sloth (material file generator), gameplay design & programming, artistic direction

Return to “Ideas & Suggestions”

Who is online

Users browsing this forum: No registered users and 3 guests