Jump to content
The Dark Mod Forums

LDAsh

Member
  • Content Count

    131
  • Joined

  • Last visited

  • Days Won

    2

LDAsh last won the day on December 11 2017

LDAsh had the most liked content!

Community Reputation

40 Good

2 Followers

About LDAsh

  • Rank
    Member

Recent Profile Visitors

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

  1. https://texturefun.com/ & https://texturebox.com/
  2. It depends on how your files are originally organised, but you can try this approach... Generate a TXT file which lists all textures filenames within it, using something like this:- https://www.karenware.com/powertools/karens-directory-printer Then use Regex to prefix/suffix the surrounding material script, using something like this:- http://dngrep.github.io/ Regex will also allow you to duplicate lines within the file along with special delimiters to differentiate them in case of order.
  3. After all these years, I had no idea this was possible.
  4. Yeah, I've seen the Mandelbrot-like art created by AI, and some more advanced stuff after AI has been fed with references to guide itself, to the point of outright ventriloquism. We're a very long way away from replacing a team of game developers with software. It seems you've been reading a lot of the fantastical articles and are all excited, like many others, but I'm just saying that I'm personally far from being overwhelmed by much of it. It's mostly boomer-noob media parroting Silicon Valley geeks looking to bolster more investment opportunities. They are just mostly other tools to use and that is all. I don't want you to get worked up over it so I won't reply anymore, we can easily just disagree. I just want to clarify about the upscaling techniques (as relevant to the thread) - if a software can automagically perform a task (or a million) it's because a human programmed it to, because another human already developed that technique. It's not something mystical, and that kind of thinking bugs me. Hence why I mentioned emulator filters and Gigapixel results, they don't look so similar by accident. If that's me being misinformed, well, I'll just carry on actually manually working, and wish you the best of luck.
  5. I would like to politely and respectfully disagree. Yeah, there are some emulators that already attempt to do this kind of stuff with textures, but the results are never pretty when weighed against the performance hit. It's interesting to toy with, but usually get turned off for long serious play sessions. A human being is always going to bring better and more significant details into the scene than a computer program ever can. A human already has all of the filters and effects the computer can use, and infinitely more. The real question is speed, time and money - that's the only reason for considering these approaches. Here's a comparison of Gigapixel in use, it's basically like using a median filter and sharpen/soften combination, much like the HQ*X/'SuperEagle' filters you can find in modern emulators, which FYI many people think makes games look ugly:- https://media.indiedb.com/images/downloads/1/191/190440/F.png Judge for yourself, if it's worth 4X the video memory demand or not, compared to what dedicated artists could do with the same demands. Once again, quite a huff made over AI that doesn't pay off on closer inspection quite as much as the runaway imagination of it. The thing is - why not batch-process every texture in the game, if humans are never going to do it. In the future, I can see developers forcing the end-user to compile textures for themselves during install, using something similar to Allegorithmic Substance, if players want 8K or even 16K+ textures without needing to download 500GB worth of content - but that's not upscaling and that's during install, not runtime, because there would be no need for that even if it was possible.
  6. There are a lot of "HQ Texture Mod" packs for everything coming out (and a lot more to come!) thanks to the growing popularity of Topaz Gigapixel AI. I see a future of a lot of wasted HDD space for very little discernible improvement. We already have texture filtering since ~1997, any software that attempts to take those sharp original texels and blur them into each other is doing so in the face of that. That's what folks need to understand. Any 'upscaling' is inevitably going to take artistic effort and the same skills as it did to originally create the asset.
  7. This is really cool, as powerful free software really is. A little warning though - this is a 7GB install and requires an Epic/Quixel account. I have doubts this software will function offline, but we will see...
  8. Ability for "Fixed Subdivisions" of "Patch Tesselation" in "Patch Inspector" to be higher than 32, or at least not cap patches back to 32. NetRadiant can currently load map files with higher values even though the GUI still says 32. I managed to get up to 4444 4444 which was many millions of triangles. I think this is a good move to help future-proof the software.
  9. Maybe I'm naive but I always associate Linux with WINE and virtual machines. If someone "switches" to Linux as their grand-daddy OS, that doesn't mean they are giving up Windows, it just means they can shove Windows into the corner and use it how and when they want, in a confined environment. After all, this is how Microsoft have been treating us, so why not us treat Windows the same way.
  10. The inconsistency is with this fork of Radiant, as the built-in editors for Doom3/Quake IV/etc display the "edge winding" of patch triangles as they actually would be in the engine:- I wouldn't hold my breath on this ever being fixed as it goes pretty far back.
  11. I think it's because it's an OS and not just a site or a program (that can be contained) we're talking about. There's not much you can do to protect your privacy if the OS itself is poking you in the back door. It's also because Microsoft are one of the very few companies to have been around for so long and have built up such a positive reputation, a legacy, for many of us since we used our first PC. Also because there are almost no other suitable alternatives except Linux and even then we'd be looking into virtualising a Windows OS or 2 with it, in order to do everything we want. I see the 20s as being the age of multiple systems, multiple HDDs and partitions that multiboot/virtualise multiple OSes for various purposes. I also see many of these companies (trying to) demand more and more of our data (even passports, etc.) just for basic use.
  12. Does not appear to be smoking any weed... https://www.youtube.com/watch?v=udlMSe5-zP8
  13. Indeed and we're doing exactly that. Radiant is still one of the fastest "level-creators" I'm personally aware of, once it's set up correctly. There are also a lot of other mappers out there who know how to use it and would love to get involved in a new project, so plenty of opportunity for recruitment. There's just nothing faster than dragging a brush and slapping textures on its faces. I have a workflow that mostly automates the process of exporting from Radiant(s) and into Blender, which I'd be happy to share privately. A custom OBJ importer and Python scripts that clean everything up and texture everything. The one thing anyone needs to be aware of is that you'd be exporting ASE/OBJ from Radiant, not the BSP/PROC files that carve and merge all geometry during compile. This has a lot of implications for all mappers to understand, especially however you'll end up portalising your worlds, but certainly not a deal-breaker. There are some fuzzy legal grey-areas about using BSP/PROC formats commercially, but everything else is fine. If you're going to use an engine that can make heavy use of vertex-buffer LOD stages, then check this out as something that can be automated for LOD sake:- http://www.violationentertainment.com/temp/VE_patchtess_190714.mp4
  14. If I really don't want to touch Blender?:- http://forums.thedarkmod.com/index.php?/topic/20008-brushwork-generators-mapgen/&do=findComment&comment=438388 I already agreed with you, batching and atlasing is important. Where I disagree is the implication that it's something that suddenly became an issue within this thread, because of this technique. You could still LOD these chunks of details like anything else, but it comes down to TDM not having a very good LOD implementation (from the HDD with limited stages VS from within vertex-buffer using more stages) and/or smooth distance-culling. You're actually pointing out issues with the engine itself rather than issues with any editing approaches or tricks. Takes much much longer, it's not very noob-friendly, and you end up with something that can't be edited in Radiant afterward, which is actually the whooole point of this (and my other terrain thread) in the first place. To do as much as possible in Radiant. Anyway, use it or don't, whatever, I just posted it here because somebody else might find it nifty. Sorry to be a nuisance. . . .
  15. But have you actually thought it through? Scatter _where_? What's the difference between exporting all the mapobjects after they've been placed in Radiant, and exporting large chunks of map (that won't be textured) into Blender, so you can see exactly where each object will be positioned in the map? Either way it would take the same amount of time, unless you're blindly littering objects on a flat surface. This is also something that should be done right at the final moment of the creation of a map, so you can always tweak these things right there in Radiant instead of having to go back to Blender and export everything over again. This is why I ask if you've actually thought this through or not. In my experience, this is easier to do in Radiant than in Blender, so a better approach is to merge and atlas everything after you have positioned them. This is mainly because texture features of a map can matter in terms of where small objects would be positioned, along with positions of other entities, and in Blender you'll just be seeing flat grey geometry everywhere and be at a disadvantage. Some folks are just more comfortable with Radiant than Blender anyway and don't wish to constantly jump back and forth between them. The other thing is, it would take longer to prep (import and fix material headers, etc) all your mapobjects in Blender, that you wish to scatter around - meanwhile they are already set and ready in Radiant. I also said in the first post this works with brushes and patches too, and other entities, it's not only concerning mapobjects. So the argument that it's somehow worse than any other approach has flopped. All this is doing is making an existing creation process quicker, it's not some bad voodoo that suddenly makes your triangles choke your GPU more. Once again - this is absolutely no different than any other occasion a mapper copy+pastes large amounts of mapobjects around manually. This is just quicker and simply just another technique I decided to try and share...
×
×
  • Create New...