Jump to content
The Dark Mod Forums

peter_spy

Member
  • Content Count

    2196
  • Joined

  • Last visited

  • Days Won

    71

peter_spy last won the day on September 9

peter_spy had the most liked content!

Community Reputation

1253 Deity

1 Follower

About peter_spy

  • Rank
    Uber member
  • Birthday 01/01/1981

Profile Information

  • Gender
    Male
  • Location
    Central Europe
  • Interests
    Photography, 3d modeling, level design

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Most beginner mappers won't make textures at all, but they will feel the limiting consequences of not optimized assets. They would have more freedom with enough preset skins and optimized assets, as they would hit performance limits later than sooner. Even now you can see the consequences of that approach: many missions look same-ish and they are unoptimized, or they limit mappers a lot. It's the same as if the assets had fewer editing options, but with all the disadvantages
  2. Not really the case of companies vs. hobbyists, as e.g. CS mappers or Skyrim mappers have to do the same, so the engines they use work as expected (i.e. maintain high framerate in competitive online play, or make the gameplay in TES engine as smooth as possible (which isn't easy from the get go). Mappers don't need high number of materials per model to have versatility, they need a decent number of skins.
  3. They use very high number of materials per model, and the material complexity is often high too. That's a textbook example of how not to make assets, for any engine really. You can easily clog the graphics pipeline this way, even in something like UE4. Since the realtime ray tracing is very young and first rtx cards are still relatively inefficient, nvidia uses older games like Quake 2.
  4. They might try it with Doom 3, although it doesn't make sense to choose tech that ultimately was a fork in a road and more of an experiment. They definitely won't choose TDM, as they need correctly made assets and as much overhead as they can get. There is a RTX-based lightmapping project in the works though (for vanilla Doom 3).
  5. IMO to make it decent, you'd need a new environment pack: modular pieces, tiling materials, single props, loot, proper sounds/music, etc. Something much harder to do would be actual characters, I think we have some basic moor AI, as Dragofer said, but not much more than that. Skeletons, zombies, and spiders would have to make do.
  6. Best solution would be to have a proper postprocess bloom for that, so the emissive texture alone would do the trick (perhaps with setting RGB to something higher than 1). Otherwise it's whatever gets the job done, without noticeable performance hit.
  7. Sorry for being blunt but glow around these lamps looks rather bad. I've been trying to find a suitable effect myself, and IMO you'd be better off with something like light that has fogs/glare2 texture and noshadows/nodiffuse/nospecular set to 1:
  8. As long as it doesn't change anything in how materials look, sure. Wouldn't go too far with HDR efforts though, such displays are still not a mainstream thing. IMO it would be great to do away with light textures for intensity at some point, switching to math formulas (locking the light resize box), and leaving texture slots only for projections.
  9. Metallic surface tests, the results are much better: There's the light hotspot issue, but again, the shading looks correct, almost the same as UE4.
  10. Okay, I did some tests for non-metallic surfaces, used UnrealEngine 4 with some stock PBR textures to have a valid reference: And in Doom3PBR: The result is very impressive, shading model looks correct. I suspect the biggest problem is idtech4 lights that may be incompatible here. This light cone/hotspot behaves strangely when you move, and when you get close to surfaces, they become too shiny: But when that gets fixed, it will look as incredible as in UE4. In the meantime I'll test some metallic surfaces too.
  11. Yeah, I agree. Even though tools like Substance have nice grayscale->channel packing options, I bet people would still use something like Gimp to tweak the textures. And working on channels in Gimp is a PITA (constant decomposing and recomposing, then exporting). Having shortcuts, e.g. pbr_Color, pbr_Roughness, and pbr_AO (just like diffusemap, specularmap, and bumpmap) might be faster for material prototyping.
  12. Since it's a vfp file, maybe you could use it the same way you use programs like HeatHaze.
  13. I'll have to verify the above, as I tried something like that in D3 vanilla, and the effect is similar. Light hotspots seem to work correctly with metallic materials, but that problem exists with non-metallic surfaces.
  14. It seems like at this point the PBR shader will be largely incompatible with TDM. I suspect it might have something to to with the vfp programs we use. I tried the 2.05 + interaction direct combo along with correct PBR textures, and the surface roughness changes way too drastically with movement, or even just standing / crouching. Edit: This is an issue in vanilla D3 as well, Icecoldduke is aware of the problem and will fix it
  15. I made that notice And it's true, the textures are incompatible both ways, although with PBR to non-PBR it can be something as simple as adding AO to base color for diffuse and inverting roughness map. Doesn't work the other way.
×
×
  • Create New...