SomaZ

Oh hey, you also have a discord account, great. Tried contacting you via the freenode chat, but this is more convenient. Long story short, I've written a blender plugin that works together with a 3d tool called Noesis3d to import id3 based bsp maps and automize lightmap baking via the cyles renderer. The results arent that great tbh, but maybe you want to have a look yourself. Last time I've tried to bake some lightmaps it had some ugly problems that were caused by the principledBrdf shader node. Not sure if they fixed the problem in newer builds of blender. Sorry for the wall of text, just wanted to get this out before going to bed.
cycles render of one of the star trek elite force maps
cycles render of one of the jedi knight jedi academy maps

illwieckz

wow, awesome
thank you for trying again to contact me on discord
I did not notice your message on irc until now and then was sad you disconnected!

SomaZ

Haha, no problem. I think you had the same idea some years ago, so I thought we might find a working solution together ^^

illwieckz

YES
That's the first time I see something that goes down to the rendering itself
I'm not sure neosis is free software, but if we manage to get a pipeline that works it would be a first step before replacing some steps in the pipeline
for example it would be possible to replace noesis with assimp but the later needs fixes at this time

SomaZ

yea, noesis is free. Its written by one of the renderer programmers of jka

illwieckz

by free I meant libre (using GPL/BSD or other licence like that), not freeware :p

SomaZ

the thing is, I kind of hacked in a little plugin for noesis to get the lightmap informations out of the bsp file. Like surface one is lightmap 2, surface 3 is lightmap 1 and so on.
Nah, but you can add plugins
Still not sure if blender is the way to go tbh. I always struggle finding a good solution to replace the lightgrid in the bsp, or better, to gather the infos that are stored in it

illwieckz

yeah, I don't know, but your screenshots are gorgeous, this is probably the most advanced proof of concept
for sure cycles is not the only one raytracer available
what I'm looking for is an raytracer supporting OpenCL

SomaZ

still, the bakes didnt work out so well. Wait, I guess I have some old comparisons between cycles render and ingame baked
so you actually want to add a raytracer to q3map2 instead of the photon mapping?

illwieckz

When I wrote that thread what I thought about was to just use q3map2 to produce a bsp (-bsp and -vis stage)
then to use “another tool ™ ” to produce lightmaps
note that it would not be stupid to still ask q3map2 to produce a rough lightgrid

SomaZ

Last time I thought about something like this I thought I might rework a software called BakingLab to produce all the lightmaps. But it only has support for one lightmap build though a dynamic sky and a maximum of one area light for now

illwieckz

hmm
note that we maybe have another solution one day

SomaZ

Just because it already builds other types of lightmaps that I eventually wanted to support in my jka renderer later on
https://github.com/TheRealMJP/BakingLab

illwieckz

I know that one of our devs (Fuma) is working on GPU raytracer

SomaZ

oh, another thing. I hacked hdr export into q3map2 some time ago: https://github.com/SomaZ/GtkRadiant
The open source, cross platform level editor for idtech games - SomaZ/GtkRadiant

illwieckz

the GPU raytracer Fuma is working on may be able work realtime on fast computer, and may be used to bake lightmap at map load for slow computer

SomaZ

Cool, that would be super awesome

illwieckz

if it goes somewhere
yes
https://imgur.com/a/c9wZ4NT
screenshots from 2019-03-11
note that he makes a special effort to get a lighting that looks the original one
that would allow a quick porting
existing maps would render as expected when switching to it

SomaZ

pretty nice so far. :smiley:

illwieckz

but I would also have an option that is not backward compatible but more physically correct for new stuff
what do you call hdr in q3map2 context?

SomaZ

no color clamped lightmaps?
like lighmaps that have values above 1.0 :stuck_out_tongue:

illwieckz

ah
note that netradiant's q3map2 also have support for sRGB lightmap, do you think it would be possible to support both?

SomaZ

ldr, vanilla lightmaos
hdr lightmaps
srgb is just another color space

illwieckz

yeah, but if one day I see your patch merged in netradiant's q3map2, I would be sure the code does not conflict

SomaZ

hm, not sure. depends on what the renderer does with those lightmaps
the hdr lightmaps are just linear space, I think when q3map2 was written they didnt think about color spaces

illwieckz

they used overbright bits :p
in any way I see a commit by DT85 named “Re-arranged toolbar a bit to look similar to 1.5”
why not using netradiant?

SomaZ

idk :stuck_out_tongue:
He started the project and I dont see many jka people using it.

illwieckz

netradiant is similar to 1.5 by design since it's just a new name for 1.5 :smile:
okok

SomaZ

Was a nice chat, but I really need to go to bed now. Its nearly 2am here and I need to go to work tomorrow. :x
Cya

illwieckz

yes
thank you for that talk!
Cya :smiley:

SomaZ

Is there a way to contact fuma? I'd love to contribute to this raytracer. I'm far from being a raytracing guru, but I still think I can help out a bit.

illwieckz

Fuma's github account is https://github.com/cmf028 You'll find his e-mail address in git commit log of https://github.com/DaemonEngine/Daemon

SomaZ

Ty ^^

illwieckz

his nickname is typecased Fuma with a big F
I don't know any other name
note that I haven't talked to him since march, he sometime pops up in our irc channel to give some news (like the screenshots I gave you) then disappear until the next time
his raytracer work seems to be a slow effort (and it looks like he spends enough time to read some very high level docs from computer scientists for that effort, and I guess he has also have a life to deal with :D)

SomaZ

Kind of the same here. Read alot about denoising stuff and raytracing acceleration structures, but never made it to implement those things, because of rl.

illwieckz

:smiley:

SomaZ

But I think working on this together makes a lot more fun and motivates for the long term.

illwieckz

yep! :smiley:
6 juillet 2019

SomaZ

Uhm, do you plan on implementing PBS in vanquished?
Not sure right now, but I think I've seen some comment on github mentioning it. I've implemented cubemap convolution in my jka renderer (based on the split sum approximation introduced in a ue4 paper). Can point you to the main sections of it if you are interested.

illwieckz

I know there is some code for PBR support implemented in renderer, but Unvanquished does not have yet PBR assets so that code is untested

SomaZ

If you need test materials, shaders, maps, just ask. I have some demo pbr stuff.
Should work just fine, since most of your renderer code is based on ioq3 afaik.

illwieckz

For what I know, this is how to write shaders: 
// Phong way:

textures/shared_wall/stone
{
    qer_editor_image textures/shared_wall_src/stone_p

    diffuseMap textures/shared_wall_src/stone_d
    normalMap textures/shared_wall_src/stone_n
    specularMap textures/shared_wall_src/stone_s
}

// PBR way:

textures/shared_wall/stone
{
    qer_editor_image textures/shared_wall_src/stone_p

    diffuseMap textures/shared_wall_src/stone_d
    normalMap textures/shared_wall_src/stone_n
    materialMap textures/shared_wall_src/stone_m
}
the material map must follow some rules on the way it is created
so each channel is found where it is expected to be
is your pbr demo stuff is under a free license? I'm planning to do a repository with demo stuff to test for implementation or regression

SomaZ

I did the demo stuff, so yea, I can prepare some stuff for you under a free license.

illwieckz

great
something like CC By SA or CC By is ok

SomaZ

Guess I'll need to find out your material map layout. I'll implemented a rmo map, roughness, metallic, occlusion.
Sure.

illwieckz

metalness is R, roughness is G
see: https://github.com/DaemonEngine/Daemon/blob/master/src/engine/renderer/glsl_source/computeLight_fp.glsl#L58-L60
The Dæmon game engine. With some bits of ioq3 and XreaL. - DaemonEngine/Daemon
it looks like occlusion is not implemented yet

SomaZ

Meh, any problem about changing it to rmo? I'd love to keep those things consistent. Also materialMap is not very intuitive to use is it? I've implemented both pbr workflows, metal roughness and specular gloss. I convert metal roughness maps into specular gloss maps internally, so I dont need more shader permutations.
Occlusion is hard to handle in id3, because you have no info about ambient lighting for lightmapped surfaces.

illwieckz

Feel free to open an issue if you think RMO is better :smiley:
I really don't know if there is standards about it
but I guess the one implementing it in Dæmon did it like "some others did"

SomaZ

I did xD

illwieckz

where?
or are you saying "you did like some others did" ?

SomaZ

I did, like I did. Dont know if it's the standard, but people started using my packed texture layout. If you define standad like: people are using it, then it's a standard. I mean people are using it. I convert the packed stuff internally, so it doesn't really matter for us. Not sure if you want to support both workflows since you got a dedicated team to work on stuff.
Sry, bit drunk right now. I am at a Metallica concert right now.
Maybe talk tomorrow about it. ^^
I'll post some links to my github repository of the renderer when I'm sober again.
8 juillet 2019

SomaZ

cubemap convolution code, I reworked parts of it, but this shows all the changed code parts: https://github.com/xycaleth/OpenJK/pull/58 code to build specular gloss images from packed textures. Can be reworked for different texture layouts. This enables us to use both pbr workflows: https://github.com/xycaleth/OpenJK/pull/59/files#diff-cae380113887ceb42568c472118ece47R2609
This add's the split sum approximation for image based lighting based on the UE4 paper. I also fixed little typo's in the blend-states.
fix for bad sun position (was always overwritten by default values) fix for inverted roughness for cubemap reflections added sunlight in cubemaps added cvar for rendering cubemaps multiple times to...

SomaZ

https://i.imgur.com/iJtKwdi.jpg
Pretty old picture, but you see how the roughness parameter works with cubemap convolution.

SomaZ

can I load a map without joining a server in Unvanquished? I always get a invalid password warning

illwieckz

yes you can

SomaZ

tried devmap "mapname"

illwieckz

delete any cvar about password in config/autogen.cfg
that's the way to do: devmap parpax (for example)

SomaZ

alright ^^
ty
11 juillet 2019

SomaZ

Prepared some pbr materials and started building a small map. Do you need other features tested? Like custom normals and tangent space tests? Do you have realtime light support in unvanqished? I mean, like map entities that dont compile into lightmaps, lightgrid, vertex colors?

SomaZ

cc0 pbr textures + my map

SomaZ

https://www.dropbox.com/s/1gbcbgdmj7dlu7i/pbr_materials_test%20-%20unvanqished.pk3?dl=0
pbr_materials_test - unvanqished.pk3
needs some work on your side though. havent put a unvanquished sky in the shader file, just alter the texture in the shader. and you need to exchange the channels in your renderer because all the textures use r = roughness, g = metallic
I guess you also need to change the player spawn entity as this was build for jka sp
13 juillet 2019

SomaZ

written a conversion substance for substance player
it can convert our texture layout to your future one (ORM) and specGloss, which I use internally in my renderer. As input it can use rmo, moxr, orm or the single pbr textures you can get for free from some websites
like from here: https://textures.one/search/?type=tex-pbr
rend2_mat_packer.sbsar
I packed ambient occlusion into the blue channel of the normal also, just because I need it in my renderer and there was no other spot. Keep this in mind as you might want to use the normal blue channel for something else. Just tell me and I can alter the substance

SomaZ

works as intended. :smiley:
28 juillet 2019

SomaZ

started writing a bsp importer for the new blender version. I think I can build a bsp patcher for lightmaps too.

SomaZ

illwieckz

wow
29 juillet 2019

SomaZ

nearly got every interesting attribute from the bsp

illwieckz

interesting! :open_mouth:
are patches supported?

SomaZ

not for now, will add them last. also need to parse bsp models and other stuff, like misc_model_statics and so on. So this will take a while. But its awesome already :stuck_out_tongue:
2 août 2019

SomaZ

partial patches support. I need to tesselate them later and smooth them out, but the base points are all there now. :smiley:

illwieckz

wow wow wow
3 août 2019

SomaZ

now it can parse quake3 shader files too

illwieckz

wow, that become a real thing
it looks like it's time to unite in a group
see what Martin Taibr already did on .map side: https://gitlab.com/martin-t/blendiant
I know he (at least at first) used some of my own code from https://github.com/DaemonEngine/Urcheon
so it would be better to unite
from Urcheon I know he used code from my esquirel tool that is parsing .map files, note that for this project I also started a .bsp parser and plan to write a .shader parser, so it would be sad if each others rewrite everything ^_^
@SomaZ do you have a repository?
does discord allows to turn a private chat into a group chat?
this is Martin handle: 
[redacted]
He is from Xonotic project https://discord.gg/0uxcsw1XMkaOB936 (development channel is #xonotic on freenode, which is not bridged with discord)

SomaZ

Hey, I haven't uploaded it yet, because lots of features are missing right now and I want to see how far I can get with all of this. Give me some weeks to finish more parts of it and make it more fleshed out. I will definitly upload it at some point.

illwieckz

don't worry, my main concern is people, I think the best way to succeed is not about uniting code but about uniting people (uniting code is then done as a consequence of people uniting together while they work)