-
Posts
438 -
Joined
-
Last visited
Content Type
News Articles
Tutorials
Forums
Downloads
Everything posted by SomaZ
-
The dummy stage actually forces the renderer to think its a solid material. Currently only solid materials can use the new lighting system (even if they actually arent solid). I will remove this restriction when I have some time because its stupid. As I said, pbr materials try to decouple lighting from the material itself. Reflections are a component of lighting. So the roughness of the material defines how much reflection you will get. Not the most physical correct explaination. Reflection is always there. The roughness actually tells how much the reflection will scatter. The stronger the scattering, the less noticiable is the reflection itself. There is no dedicated reflection stage for cubemaps. Else you could not use the material in other places without defining a new shader with a different cubemap assigned. EDIT: For a water shader you probably dont need a rmo. Theres no real occlusion happening, and you dont have metallic components. You can just skip that map completely. You can just define the roughness per stage with the keyword "roughness 0.5" for something that is more rough, "roughness 0.1" should be fine for water like surfaces. Since you scale down the reflection with your blend, you can counter it with "specularreflectance 0.0-1.0". If you have a uniform transparency of 0.08, your specularreflectance should be around 1.0, the less transparent, the less the reflectance. Like uniform transparency of 0.16: specularreflectance should be 0.5 and so on. At least thats how I handled glass. Water might be more reflective overall. Assuming you use a texture without alpha channel, your shader could look similar to this textures/rend2/water { qer_trans 0.5 { map $whiteimage alphaGen const 0.0 alphaFunc GE128 } { map textures/rend2/water normalMap textures/rend2/water_n specularreflectance 1.0 roughness 0.1 alphaGen 0.08 blendFunc GL_ONE_MINUS_SRC_ALPHA GL_SRC_ALPHA } { map $lightmap blendFunc GL_DST_COLOR GL_ZERO } }
-
Some little hints on exporting textures from substance painter to rend2 / gl2: Export preset for the roughness metallic workflow looks like this: Export preset for the gloss specular workflow looks like this: Example pictures:
-
Hm, I'm totally invested in the Substance 3D suite. I have very little experience with free tools regarding pbr tbh. I know about ArmorPaint and ArmorLab which looks actually pretty good on first glance https://armory3d.org/ Theres also alot of free CC0 licensed materials here http://www.3dassets.one/#license=cc-0&type=pbr-material&order=latest Quixel Mixer is kind of free. Adding free materials is annoying though, but its a really nice software overall https://quixel.com/mixer Blender is also potentially viable if you are familar with that. Though the workflow consists of baking your maps manually, which can get annoying. Cubemapping needs to be enabled via cvar: r_cubemapping 1;vid_restart It will use deathmatch spawn points to create them on level load, or you place new entities with "classname" "misc_cubemap", "radius" "#your_parallax_correction_radius", "origin" "#origin_obviously". Parallax radius is not very intuitive tbh, I'd start with something big like 1000 and reduce or increase when reflections behave strangely. Surfaces use the closest available cubemap around them. Theres another way of defining cubemaps via a json file, but this feature is like 100% undocumented. I added an export to my blender addon for the file, but also not public yet and undocumented. The darkening would be a seperate material stage, so yea. Bascially like in vanilla. Theres no specialized way of doing it in rend2 (yet). You might be able to blend those based on vertex alpha, but havent put much thought into it. EDIT: Havent tested any transparent surface with cubemaps for a long time. You might need to add a "solid" dummy stage first that actually draws nothing. textures/rend2/transparent_cubemapped { { map $whiteimage alphaGen const 0.0 alphaFunc GE128 } // your transparent layers after that }
-
Yea, I'm sorry for the lack of resources regarding rend2. I started writing a tutorial series, but its far from beeing finished. The main idea of the new material system of rend2 is the usage of a pbr material pipeline. It decouples lighting information from material information. Means, theres no diffuse texture anymore, but a simple material color (also called albedo or basecolor) and some maps defining material properties. Like normal maps. The RMO texture (or ORM or MOXR) is a packed texture. It actually consists of 3 different gray scale textures defining different material properties. R stands for roughness, M for metalness, O for occlusion (ambient occlusion or cavity occlusion), X is a spare channel that is not used. So RMO textures pack roughness in the red channel, metalness in the green channel and occlusion into the blue channel of the texture. Here is an example image made by @AshuraDX I started remaking the bespin duel map with rend2 in mind last year, but found rend2 to be too unfinished to release anything yet. Had to change normal map handling and some other things that are mostly finished now. So expect a sample map with some nice rend2 tricks soon. Also working on a blender addon to bake proper lighting for rend2, which also took alot of time. Hope to release this beast with proper documentation this year. More on that also soon. Hope this helps at least a bit with your current project. Really like the aesthetic so far. I'd probably add some darkening for the wet sand near the water line to make it look even better. If you have further questions, I'm happy to answer them. EDIT: Whoops, totally forgot about the liquid shader. The liquid shader is only implemented in gl2 which is the df2 mod fork of rend2 for sp. There are no plans in porting this over to rend2 as the code is quite messy. But never say never
-
Vertex normals seem to be ignored by your blender version / addon combination. What versions are you using?
-
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?
-
What would cause light issues around a func-door?
SomaZ replied to OCD2's topic in Modding Assistance
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. -
What would cause light issues around a func-door?
SomaZ replied to OCD2's topic in Modding Assistance
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. ?