Jump to content
The Dark Mod Forums

Search the Community

Searched results for '/tags/forums/reference material/q=/tags/forums/reference material/' or tags 'forums/reference material/q=/tags/forums/reference material/&'.

Didn't find what you were looking for? Try searching for:

  • Search By Tags

    Type tags separated by commas.

  • Search By Author

Content Type


Forums

  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...


Date Created

  • Start

    End

Last Updated

  • Start

    End

Filter by number of...

Joined

  • Start

    End

Group

AIM

MSN

Website URL

ICQ

Yahoo

Jabber

Skype

Location

Interests

Found 13423 results

  1. Arcturus
    Elite merc is one of the better looking NPCs in the game, but I think we can improve couple of things. New material looks like this: I modified the specularmap slightly. Since he has a sword i updated that too: The handle and blade use different cubemaps. There's no reason why elite guards shouldn't have polished shoes. Although the uv mapping on those is atrocious so don't look too closely. That's why the fronts of the soles are too shiny. Importing and fixing the .md5 mesh in Blender is practically impossible because of this issue: Not that I want to get into that. I think the excessive shininess of soles can be mitigated by creating a separate specularmap, as the boots and armor are in separate materials.
  2. datiswous
    Wiki page https://wiki.thedarkmod.com/index.php?title=Security_Camera_(2.10%2B)#Sending_the_camera's_view_to_a_Display_Screen says: If you want to use a functionality where you would use multiple camera's pointing at something and multiple screens, is it mandatory to use material code map "_cameraN" // (N = number, for example 1, 2, etc.) ? So precisely that word with underscore in front. That's what I think, but the wiki page doesn't take other use cases into account where you would use a different material file with other settings. I was thinking of adding that info.
  3. Arcturus
    I believe mirrors have been rewritten completely at some point. As I mentioned this material doesn't interact with lights so it has very limited use cases.
  4. MirceaKitsune
    If blurry reflections didn't look nice in all cases, why not just remove the resolution in the material definitions instead of disabling it globally so those who want them could still use those parameters? Makes more sense to allow a resolution of "mirrorRenderMap 0 0" to specify you want to use the screen resolution. I'd probably use it for those floors: Blurry resolution would look better, plus I gain a lot of FPS just for having it that way! Is there a good reason why it was disabled this way? In the meantime I'll likely give your material a try as the result clearly looks better: Thanks for sharing that! I was wondering if I could bend the reflection with the texture's normal map but didn't hope for a way. I'll definitely want to put the specular map back on as I don't want to lose its effect either.
  5. peter_spy
    Why? When I make assets I always use default values, and I think it's pretty much the only way to ensure everything looks the same on all players' computers. Obviously they can set it up as they like, but they have an easy reference point, in case they want to return to intended look. Besides, in order to get consistent results, you have to at least try to assume a model, something that will return somewhat logical results. Since this is non-PBR, it's hard to do; you don't even have any consistency in how models, materials or other declarations were made, nor how mappers use lights in maps.
  6. Arcturus
    r_bloom_weight is set to "0.7" both in my 2.12 installation and in main repository. I never touched those values which means the default must be 0.7. Troy Sobotka is the original creator of AgX. He was active on Blender forums where he had long philosophical arguments about color with people. Also on Blender developer forums. I don't know if there's much more beyond those and his github page: https://github.com/sobotka Edit @stgatilov AgX however is a direct continuation of Sobotka's earlier 'Filmic', so there may be more about that: https://github.com/sobotka/filmic-blender https://blender.stackexchange.com/questions/164991/are-the-technical-details-of-filmic-available
  7. MirceaKitsune
    Getting to try realtime reflective floors in practice. Took me well over an hour to figure it out but the setup for a complex shader is ridiculously simple, all you need to do is add a "mirrorRenderMap 256 256" with a "blend add" to any material. FPS is reduced a bit of course but no big deal in a closed space, I'll improve it from the lighting which I abused a bit in this scene.
  8. Arcturus
    In Blender in "standard" view transform if you take a pure red, green or blue emission color then it doesn't matter how big the strength of that light will be, after certain threshold it will stay the same color. This works the same way in Darkmod. If you set a light or a 'shadeles' material to pure red, green or blue, when increased in brightness, after certain point it will not change at all. In this example at high light values, details in the carpet start to disappear. Newest view transform in Blender - AgX does something different. It will start to desaturate the color after certain point to compensate for the increased brightness: This is how bright lights are typically rendered, with a white core and colorful bloom around: The code that chatbot generated for me does not do that. Primary colors stay saturated at high values. But the details in the carpet are better preserved: There is a simple workaround, though. Just add a little bit of other primary colors to the mix: table tonemaptable_01 { { 0, .1, .2, .3, .4, .5, .6, .7, .8, 0.9, 1, .9, .8, .7, .6, .5, .4, .3, .2, .1, 0 } } lights/tonemap_light_red { { forceHighQuality map lights/biground1 colored zeroClamp red tonemaptable_01[time*0.15]*10 green tonemaptable_01[time*0.15] blue tonemaptable_01[time*0.15] } } tonemap_emission_red { noShadows nonsolid { blend add forceHighQuality map _white red tonemaptable_01[time*0.15]*10 green tonemaptable_01[time*0.15] blue tonemaptable_01[time*0.15] } } How it looks right now: With custom GLSL: Currently: Custom:
  9. MirceaKitsune
    I had an interesting idea in regard to how the TDM engine handles Z-fighting. It comes after my last FM where people reported terrain patches that were too flat causing visible Z-fighting with the ground brush: It seemed weird as both surfaces had the same shader and their mapping lined up, therefore even if the surfaces overlapped the same pixels should have been fighting with no visible artifacts. Turns out the engine makes it so even if the material and its relative mapping is identical, the surface also becomes brighter whenever there's overlapping. I was wondering if unless we're stopped by deep limitations in OpenGL, there is at least a way to get rid of this brightening effect. If we have the ability to control how Z-fighting is handled, I had an idea which could turn it into a great feature available in other engines: My suggestion is to mix the colors on all material maps, so instead of randomly adding them together we settle for the average of all Z-fighting surfaces per pixel. The reason this would implement an useful feature is if we could do it per map, we'd have support for mixing the albedo + normal + specular maps on multiple surfaces in realtime, something not currently possible unless done by the texture or material. Imagine a graffiti drawing on the wall: We could deliberately have the decal perfectly overlap the surface of the brush instead of having it suspended a bit in front... doing so would cause both the albedo / specular / normal maps to be combined, lighting would then follow the bump map of both the brick as well as the decal so both produce depth on top of each other on what would still appear to be a single surface. Even if my particular idea isn't possible, it would be nice if we could at least get rid of the brightening; Z-fighting would still occur, but at least it wouldn't be as obvious if you don't look closely.
  10. stgatilov
    Another example from: Should now work fine with explicit groups: The sequence of stages here is SDBBB...BBB (ignoring ambient stages). Implicit groups detection will see many bump stages and partition as [SDB][B][B][B]...[B][B][B]. While interaction separators at material start/end are optional in terms of splitting the groups, they do switch from implicit detection to explicit detection --- that's all we need. Since separators are only at start/end, all the stages will get into single group with many bump stages. As long as conditions are correct, we will get exactly one bump stage active at each moment.
  11. stgatilov
    Every material consists of global keywords and stages. Stages are classified into ambient stages and interaction stages (diffuse, specular, bump, parallax). Interaction stages are partitioned into interaction groups. Each group is rendered as single draw call with interaction shader, its stages supply various settings (e.g. diffuse texture is taken from diffuse stage, specular texture from specular stage, etc.). Ambient stages are all extracted into separate list and rendered in their respective order. But this always happens after all interactions are rendered. In 2.12 and earlier, interaction groups were detected dynamically during rendering. There was some preprocessing code which was static (sorting stages, adding implicit bumpmap) and some additional detection in rendering code which was dynamic because it checked conditions. In the recent TDM version (hopefully in 2.13 too), the old approach is replaced with two new ways to detect interaction groups: implicit and explicit. Both ways are fully static and implemented straight during material parsing. Implicit detection. We go through stages in their definition order and add each new stage into the last interaction group. If the last interaction group already contains a stage of same type, then we finish that group and start a new one with the current stage. For instance, if we see interaction stages DSBBDDSBSD (abbreviated by first letters), it will get split into [DSB][BD][DSB][SD] groups. This should work fine for simple materials with one stage of each kind. It should also work fine for vertex-blended materials because they should have each group starting from bump stage (and hopefully they don't have duplicate diffuse stages). Explicit detection. There is new material keyword: interactionSeparator. If at least one such keyword is present in material, then explicit detection is used. Each interaction group consists of all the stages located between two consecutive interaction separators. The stages before first separator are put into a group too (if any), same applies to the stages after the last separator. Note that disabled stages are ignored during runtime, so it is possible to have several stages of the same kind in an interaction group, as long as at most one of them is enabled at any time. Explicit approach can be used for non-trivial cases, especially when stages are enabled by condition (like e.g. animated textures).
  12. Arcturus
    I'm not talking about bloom. All of the window materials are glowing in the dark. Many of them use blend add and make things in front of them brighter, when they should be making things darker, like in real life. My scepter material doesn't use blend add, it does use gl_dst_color, gl_src_color though. If we're talking about bloom, it would be a lot more useful with proper tonemapping. I can make fire much brighter so I get bloom, exept color values are clipped so I lose all detail.
  13. Arcturus
    @nbohr1more On second thought this isn't really a problem with the scepter material, but more with that large ice pane material. A little bit of both. The ice blurs everything in front, but normally it's not that noticeable.
  14. Arcturus
    I uploaded the heathaze with stronger blur but in the end with only 4 samples, like the old one, even if it looks worse. I needed it for the scepter material. I added a separate normalmap for the refraction effect.
  15. peter_spy
    IIRC, setting custom resolution to mirrorRenderMap stopped working a few versions ago, the output is always at game resolution. That blur effect looks good, we could have frosted/steamed glass now. But, I worry about the performance cost. That said, even if you try making such material in UE4/5, you'd get a huge performance drop too, at least in the editor windows. Probably best to use it sparingly anyway
  16. nbohr1more
    I think _currentRender uses the whole framebuffer but perhaps we can add something similar to the r_fboResolution cvar as a material flag. I'll look at the code. Maybe _currentRender is still hooked into the old Doom 3 generated texture system ( a sort of precursor to FBO homemade by Carmack ).
  17. Arcturus
    I made a new env cubemap called "sparkles" which I applied to the scepter. The original material: New: Is there any lighting setup where blend gl_dst_color, gl_src_color may break?
  18. Arcturus
    @peter_spy This is two separate materials, one for parallax, one for reflections. Edit: It can be simplified further by cramming parallax into second material and putting it in front of a black surface. We can get rid of the normalmap from the parallax stage, it even looks better without it in this case.
  19. revelator
    well the soundcard is kinda the pre amplifier needed for the amplifier a good soundcard can make a big difference if using the pc for sound production. TEAC makes quite good gear for musicians, technics made one of the best turntables for dj's the Technics SL-1200GR2 and also makes some quite nice amps. the turntable is quite costly though so if you got one you could easily sell it for a pretty premium it weighs 12 kg and is made in shock absorbing rubber material and alu.
  20. Arcturus
    @peter_spy In this particular material parallax mapping isn't useful. For one thing, it doesn't interact properly with cubemap reflections (at least for the time being). They are drawn on top of non-parallax surface. And with the distortion effect on top you can't really see the parallax effect beneath. parallax without distortion: With distortion: Without parallax: --- Having isolated bright spots in the cubemap makes a sparkle effect. Also having negative specularmap creates an interesting effect but it deosn't work in 32 bit the same way, unfortunately.
  21. taffernicus
    I hope there is an updated version of the jon stokes book that comprehensively discusses the current generation of CPUs from ARM, intel or AMD. Unfortunately only stuck on core 2 duo. The joy of revisiting pc hardware basics. I'm still not satisfied with the computer architecture material when i was in college
  22. Arcturus
    The earlier method for mixing metallic / non-metallic in a single material has its drawbacks. It doesn't work in 32 bit mode, so you get a material that's different for different users. You can't tweak it exactly as you like in 64 bits without breaking it for 32 bit users. It doesn't work well with current frob highlight, and while it's not the end of the world, it inverts colors in the cubemap, which is stupid.
  23. peter_spy
    Using detail normalmap as a way to control surface porosity seems like an overkill Especially since blending two normalmaps together (base + detail) is such a hassle on shader level. Having multple and complex stages in the shader increases the amount of times surfaces have to be redrawn, so it's also performance intensive. The only solution I thought of would be to have different cubemaps for different metals, depending on how polished the're meant to be. If I want slightly duller surface, I'd use a blurred generic cubemap with alpha mask. If the metal is polished, I'd switch it to an envshot from a certain location. At this point, it would probably be more efficient to port PBR solution from RBDoom3BFG, so you can control all of this with a single roughness map. Every hacky or convoluted solution increases material authoring time, and I guess most people have neither time nor energy for that.
  24. Frost_Salamander
    I've released an update for this, details here: https://github.com/FrostSalamander/lt3/releases/tag/4.0 The main change is to the reflective water material, as it was causing a performance issue in 2.13. This new version includes a new material from @nbohr1more which looks the same but doesn't cause performance issues. The release also includes a couple of bug fixes and gameplay improvements. It should be in the mission database soon, but here are download links in case anyone wants them: Proton: https://drive.proton.me/urls/FTE3WRST48#yvnLUZBtBpDD Github: https://github.com/FrostSalamander/lt3/releases/download/4.0/faffairs.pk4
  25. datiswous
    Just reporting that while further playing it also happened with material: models/darkmod/potions/potion_purple_blendaway Same fix as previously works.
×
×
  • Create New...