SomaZ

Hm, it's hard to tell what causes the issue without access to the map nor the compile settings you used. My guess is that you are using external lightmaps? Using GLdirect is always a bad idea tbh. We have the source code. If you encounter problems regarding rendering (without GLdirect), open an issue on the OpenJK Github page, so it can be fixed properly.

Oh, in this case you should at least add a fixed gloss/roughness value to your stages with specular images. Those textures weren't authored for a pbr material pipeline. Try this for an example: textures/strombine/paint01 { qer_editorimage textures/strombine/paint01_d { map textures/strombine/paint01_d.tga normalmap textures/strombine/paint01_h.tga specularmap textures/strombine/paint01_s.tga gloss 0.3 } { map $lightmap blendfunc gl_dst_color gl_zero } } Should work just like in vanilla. Are you talking about glow stages or light emitting shaders?

Try removing the rgbGen vertexLit from your first stage. On a side note: Looks like you are using standard specular maps. Rend2 uses the alpha channel of the specular map for glossiness of the surface. If you don't provide a proper gloss map in the alpha channel, all surfaces are super reflective. The specular workflow is prone to create bad materials. I'd recommend switching to the metal roughness workflow instead

Must be an error in the engine. I probably fixed it already in my latest WIP version. Never really encountered this issue before.

Currently there's no easy way of finding the location of a shader. The surface you showed in the screenshot probably doesn't even use a shader, but just the texture. If that's the case, you can make use of the auto loading of material textures. Rend2 will automatically find normal maps for files with the suffix of "_n", normalHeight maps with "_nh", packed maps with "_rmo" and specular gloss maps with "_specgloss". Means, if your material uses "textures/example/test.jpg" as a diffuse texture, rend2 will try to load "textures/example/test_n" as the corresponding normal map.

The stage qualifiers are gone for a while now. Using .mtr files require .shader files of the same name to be in place. Your file extension is .mat which is not supported. Corrected shader looks like this textures/korriban/k_ceiling { qer_editorimage textures/korriban/k_ceiling.jpg { map textures/korriban/k_ceiling.jpg normalHeightMap textures/korriban/k_ceiling_n.tga // normalMap for images without parallax height in the alpha channel // if you use a packed material definition // rmoMap is packed roughness, metalness, ambient occlusion in red, green, blue channels rmoMap textures/korriban/k_ceiling_s0.tga // if you have a specular texture with glossiness in the alpha channel use: // specMap textures/korriban/k_ceiling_s0.tga } { map $lightmap blendfunc GL_DST_COLOR GL_ZERO } } More info on the rend2 shaders can be found here. The liquid shader is not implemented in rend2 though.

Hey! Currently refactoring the whole addon to be easier to maintain and also adding some new features like pk3 support. Target version of the new version will be Blender 3.0, though I'd like to keep it 2.93 compatible. You can get the latest working wip verision (Blender 2.83 - 2.93) on our discord. Link is in the first post. Direct download link (Blender 2.83-2.93): Latest release with current code from Github

Yea, I remember. Was part of the dev team before it died. All I can say is that everybody from the team was disappointed how it went. We really wanted to release at least something, but because of legal problems we weren't able to.

I'm sorry, but 2.81 simply won't be supported anymore. It had some bads in the material system and they finally fixed them in 2.83. It would be a huge task to support older versions, or more precise it would clutter the code so its not very readable anymore. And that's not very nice to work with. 2.83 is in fact the most ideal version of blender right now as its the long term support version of 2.8. When 2.93 arrives, this will be the new ideal version to work with.

Found the problem and fixed it. I uploaded the updated renderer to our repository. You might want to set r_refraction to 1 to get the push/pull effect back. You can also delete your current config and start with a fresh one. Refraction rendering is on per default now

Looking great! I'll try to reproduce the issue you have and fix it asap. Would you mind sharing your config file with me?

Ah sorry. I missed your message. Hm, hard to tell whats wrong, simply because this version of the addon is very outdated (note to myself: make a new release on GitHub). You can get the latest version when you download the current code from GitHub. You need to repack it into another zip file though. Extract everything, and pack the "import_bsp" folder into another zip file. You can install the new zip file afterwards. You might need to restart blender after you installed it. The only Blender versions working with the latest code are Blender 2.83 to 2.91. If you still run into problems, you can always join the discord server I linked in the first post for quick help. It could be used for mapping to some extend, but its complicated. For beeing able to write bsp files from scratch, I'd need to write some nasty things like collision mesh generation and visibility computation.

Hm, do you have cubemapping enabled? Cant tell from the images you posted. r_cubemapping 1;vid_restart

Haha, what are they celebrating? "Surprise mechanics"? :'D

@AngelModder I'm currently writing a tutorial series regarding precomputed lighting in id tech 3. Lightgrid is also part of it ofc. I do this to educate people to use my blender addon for baking new lighting in blender instead of using q3map2. If you have questions regarding lighting right now, you can ask me on discord.

Nice progess so far! What I really want to see is removing the stupid shaderlist.txt. Is there any good reason to have it?

You put all the brushwork into func_statics? Can you show us the topology of your hallways? It's hard to find a solution from just a few ingame screenshots and a desciption.

Are you using misc_models for the geometry? Try spawnflag 4 on those models and recompile the map.

@Aldro Koon I have no idea about how the network code in jka and also in ja+ works. You should ask someone more knowlegable about this.

This is mainly a tool to fix things you can never get right in radiant. Sometimes vertex normals end up not beeing smoothed or you simply pull your hair out trying to get some nice lighting. (Vertex normals are used for "phong" shading, so you can actually force faces to be smooth in my plugin after compiling a map) So basically you can use this to beautify your maps afterwards. You don't need to decompile the map or else. Just patch the bsp file directly with this addon. Yes, we can actually entity mod through this. This is basically unfinished, but it already works like a charm. I think only rotating stuff is unfinished actually, rest should be fine. Also, just patch the bsp file directly with the addon. No need for another software. No, this can't decompile maps into .map. FFA3 with some new baked lightmaps for the gl2 renderer Very simple enitity mod of mp/Duel1, added two misc_model_statics Lighting works perfectly fine with this addon, when you put some effort in reworking the lightmap texture coordinates manually. You can save them back into the bsp to get no light leaks. Whoops, forgot to repeat the best thing about this. You can patch the vertex colors and the lightgrid too. Means, you can light everything in blender. Older approaches could only bake lightmaps. Vertex colors are used when a surface doesnt have a lightmap. In the vanilla game, there are lots of vertex lit surfaces. The lightgrid is used to light players. So, now you can rework the lighting completely in blender and not just make it better. Guess I should show off some drastic light changes like, yavin at night or something like that. ?

Upcoming new Features in the next update Blender 2.83 support Light baking in Blender: Entity modding: MD3 Import: MD3 Export: If somebody is interested in testing: Current development branch https://github.com/SomaZ/Blender_BSP_Importer/tree/ent-lighting-modding

Looks awesome!

The sample size tells q3map2 the size of a lightmap pixel in game units. So, if you decrease the sample size, your lightmap gets more accurate and vice versa. The game hardcodes the max lightmap count to 256 I think, and your compile said you had 566. So you needed to reduce the lightmap count. Increasing the space covered by a lightmap pixel means you can put more surfaces into one lightmap -> you'll get fewer lightmaps. Now you can try decreasing the sample size again for your compiles to get some better lighting untill you reach the lightmap limit of 256.

-samplesize 256 In bsp phase AND in the light phase