Jump to content
The Dark Mod Forums

LDAsh

Member
  • Posts

    234
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by LDAsh

  1. It says I don't have permission to view the topic, I'm not a member of the secret cubbyhouse. 73MB is quite the chubster, though. I'd also like to find out if there are some tricks to optimise performance in Radiant beyond view-clipping and regions, if anyone knows tricks?
  2. I'm interested in stressing Radiant on different systems and thought the most thorough way would be to use TDM maps. I've only looked at some of the largest downloads so far and the biggest I've found seems to be "Behind Closed Doors" at 45MB. So, I'm talking about the actual .map file, the most complex brushwork coupled with the largest areas, not the .proc file or entire PK4. If anyone knows what are some of the larger ones, perhaps is not listed on the main website missions page, maybe still in beta, I'd really appreciate it. Just out of general curiosity also.
  3. I just realised you can actually CTRL+A in there... by pressing your J key before you try it. (*this will select-all even if hidden, unlike the previously mentioned method)
  4. That's because it's easier to do that later than to split things apart that are already joined. I already explained how to do this in Blender, by joining everything together first and then 'separating vertices by material'. No idea about MilkShape because it's been a great many years since I used it. After doing that, every triangle that uses the same material will be part of the same object, even if it's on the opposite side of the map. This is exactly why you wouldn't want it done at the exporting process, it will give you the opportunity to also split the environment up based on portals. With nothing selected (ESC), you can press I to 'invert selection' and that's the best way to select all.
  5. This is all certainly possible and actually has been since you first posted about it, and I tried to explain how. Now, DarkRadiant can export all your mapobjects too, with UVs and headers. So you get your brushes, patches and mapobjects. There is some fiddle-work involved in preparing it for use in another engine and there always will be, so if you'd like help with the fiddle-work, let it be known where you're getting confused about it. However, if you'd like to wait for easy one-click solutions to this, like something that will automagically examine the pixels of every texture and decide which best matches to replace it with, etc, then the very best of luck with your waiting.
  6. Sorry, I really did mean "minimum system requirements" and not "what buy to get all shinies" For example, is saying 64-bit another way of saying "32-bit no longer supported"? That tends to happen with software, I've noticed. With everything beaten down in a CFG would the project still run on a dual-core system? All the CPUs mentioned seem to be (unsurprisingly) at least quads, if I'm not mistaken.
  7. Pretty cool stuff. Any info about if/how much the minimum system requirements for the project will increase? I am into poking at it as a beta-tester, if more fingers in the cookie jar are wanted.
  8. Hey, thanks a lot Snehk, I really appreciate the binary. Editor is working just fine, which is what I was mostly interested in. Engine in general is interesting although without decent content it's difficult to draw any worthwhile conclusions. Just wanted to say thanks and bump this, since it almost flew under my radar and I was about to give up.
  9. I'd really like some help too, with getting binaries, because I'm getting errors installing the Visual C++ Community Edition and I don't wish to make a mess on my system just to compile 1 thing 1 time... Maybe one day I'll get another HDD and install a copy of Windows that I can garbage up with all kinds of different SDKs and IDEs, but for now I just don't want to deal with it. Suddenly the GPL source release issue seems like a thing, but 99% of the time the "developers" are like "Yeah, the source code IS made available... on my HDD... and yearhrh I'll totally send it on over to you, like, next week after my mom maybe dies of cancer? But actually you'll never hear from me again hey." Or, if some instructions on how to use a different (more "lite" and more friendly) IDE to compile this with, that would be wonderful.
  10. Nice work? No, looks like I'm going to need to make a chunky-ass macro to fix all the material headers automatically...
  11. So yeah, MeshLab can certainly do this:- ...but with a couple of important caveats. Here's how anyway:- _______________________________________ Convert ASE to OBJ, change any "/s" into "!s" (to (try to) preserve full material headers), and import mesh into MeshLab:- Filters > Polygonal and Quad Mesh > Turn into Quad-Dominant mesh - (Optimize For: Better quad shape) Filters > Selection > Select non Manifold Edges Filters > Remeshing, Simplification and Reconstruction > Planar flipping optimization - (Planar metric = area/max side) (Post optimization relax iterations = 0.0) ...then export to OBJ, which is a different version that Blender doesn't seem to like, but there are converters to fix that. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ So the issues are - I can't seem to reliably retain the material headers, and it will also reposition the mesh to the middle of the object on exporting, which may or may not be a big deal depending on the proportions of what is exported. This can probably be circumvented by encasing everything in a giant cube, possibly. MeshLab's OBJ exporter doesn't have a lot of options there, so although it does work, the material header issue is the deal-breaker for keeping it an efficient overall solution. It prefers the filename over the material header, unfortunately. If it were as simple as this 4-quad 1-material test, sure, no biggy, but in practice we'd be shoving around (tens or even hundreds of) thousands of triangles, with dozens of different materials, and it's just not reasonable to spend hours in a text editor, fixing every damn material header, every damn time.
  12. I'd really like to fix the way the ASE exporter (and others) orientates the middle edges of the quads it exports. They are opposite of how they should be, as seen in Radiant. To illustrate, I have this pic below - on the left is the original patches that I exported, and on the right is the ASE model that I imported back into Radiant. You'll see how the inner edges are orientated differently, and in this case gives a different shape, and in other cases may affect the way the textures are warped on these faces. (I added the extras lines in the orthographic view to demonstrate this, but they are 4 patches, not brushes) I'm also trying to figure out how to do this in Blender, but I don't think it's possible. Perhaps Meshlab can do it. There is a line in the Python script here:- for x in reversed(winding): verts.append([x.vertex.x(), x.vertex.y(), x.vertex.z(), x.texcoord.x(), x.texcoord.y() * -1, x.normal.x(), x.normal.y(), x.normal.z()])A tweak to this may be what's needed, but I have no idea how. I might try to play with it in a while. Exporting as OBJ corrects the orientation of the inner edges of the quads, but using this method loses the material headers, this information is not exported.
  13. Legally, there doesn't seem to be an issue with collecting charity for the project, but you just need to weigh the few dollars you might get from people against the potential damage it might do your reputation from those who might have otherwise helped later on in more substantial ways.
  14. You can 'open URL' with SMPlayer, or download with Freemake. Sometimes I get errors with SMPlayer but that has nothing to do with age-restriction, and sometimes Freemake has audio issues but that's been very rare.
  15. Is it just me or has the "Window Layout" option gone missing? I am so used to the orthographic view being on the left, but this can be fixed in the XML settings files anyway.
  16. Okay, I already understand that rotation is achieved by skewing both axes of the UV and that's originally why I started toying with those values, and it's a very impressive-looking post, but didn't actually provide any useful practical information about how to translate the values between texel-scale and rotation. I should have been more specific, the rotation is not really the issue by itself - it's rotation that matches the texel scale of other textures, that's the important thing. Using slow tweaking methods, I have some numbers that seem pretty precise and do what I want:- ( -1 0 0 256 ) ( ( 0.001953125 0 0 ) ( -0.000977 0.001953125 -0.125 ) ) "texture" "-0.000977" to skew and "-0.125" to readjust it vertically to match its neighbouring brush. This is using a scale of 0.125 and will vertically skew the texture 22.5' (actually it's 26.5' because we're dealing with 8s and not 10s, best I can explain it) so that for every repetition of the surface, the skew is aligning the texture half-way, so it won't perfectly align again after double that width. So what that means is, if you have a 2048x2048 texture and the surface is only half that height, showing only 1024 rows of texels, you can show the entire texture along double the horizontal scale by skewing it vertically, and the texels will align and match up again after what would take 4096 columns of texels, and you could say you have 1 unique texture that is actually double the width and it's also not wasting anything. The numbers are tweaky guess-work and 0.000977 is not going to be precise over vast-distances, there's obviously a few more decimal points needed there, but lines up pretty well for what I need. Seams will not be noticeable unless doing it over vast distances. Ultimately, the best solution would be to just use the "patch mesh over flush caulked brush" trick, or just use an external modelling program and import a mesh, then you'll have easy precision without text-editing the map file, if that wouldn't cause any issues. http://www.violae.net/temp/skewy_brushes.jpg
  17. Copy and paste the "shader" from a patch won't work because it would be the UVs that are causing the skew, not the surface properties. Making a separate material for every skewed variation doesn't sound like the optimal approach, either. I will just keep trying to figure out how this number "0.0013810679" possibly relates to 45'. If it would be made into a DarkRadiant feature, I guess the same mathematical formula would need to be worked out, anyway.
  18. You can use the Texture Tool to do this on patches, but not on regular brushes. Trying to move just 1 vertex will move the entire quad, so skewing the texture is impossible. Turns out this "matrix dialogue" I was dreaming about was actually in Q3A Shader Editor, the "tcMod transform", which could skew textures via the shader script. Stupid faulty brain and its phantom memories. I could swear something similar was in a Radiant somewhere... After some more experimenting, I can get the angles correct by rotating the texture, saving, and then text-editing the map file and removing one of 2 values the rotation is stored as. _______________________________________________________________________________ original:- ( -1 0 0 528 ) ( ( 0.001953125 0 0 ) ( 0 0.001953125 0 ) ) "texture" rotated:- ( -1 0 0 528 ) ( ( 0.0013810679 0.0013810679 0 ) ( -0.0013810679 0.0013810679 0 ) ) "texture" skewed:- ( -1 0 0 528 ) ( ( 0.0013810679 0 0 ) ( -0.0013810679 0.0013810679 0 ) ) "textures" _______________________________________________________________________________ So the vertical angle is now exactly 45' but the texel-scale is not correct. Trying to adjust it in Radiant with the surface inspector breaks the skewing and it becomes rotated again, and trying to make sense of these numbers with text-editing is mind-bending, although I'm sure there'd be a way to do it. Could this be an interesting enough technique to warrant a feature request for upcoming DarkRadiants?
  19. I know this is possible and I vaguely even remember a "hidden" dialogue in the editor which was like a matrix of texcoord values to screw around with, and we were able to skew textures (precisely) instead of simply rotate them, but this was many years ago. I can't remember if it was the built-in editor for Doom or even GtkRadiant. It can be done by editing the .map file in a text editor, like so:- { ( 0 0 1 0 ) ( ( 0.125 0 0 ) ( 0 0.125 14 ) ) "caulk" ( 0 1 0 -512 ) ( ( 0.125 0 50 ) ( 0 0.125 40 ) ) "caulk" ( 1 0 0 -536 ) ( ( 0.125 0 1 ) ( 0 0.125 0 ) ) "caulk" ( 0 0 -1 -192 ) ( ( 0.125 0 0 ) ( 0 0.125 50 ) ) "caulk" ( 0 -1 0 -512 ) ( ( 0.125 0 14 ) ( 0 0.125 56 ) ) "caulk" ( -1 0 0 528 ) ( ( 0.001953125 0.0025 0 ) ( 0 0.001953125 0 ) ) "texture" }This last line, the 6th value, I changed to from 0 to 0.0025 and it skews the texture vertically but not horizontally. I can't figure out how to get a precise angle like 45' or 22.5' and to keep the proportions and texel-scale of the texture, which is really important. There's a lot of reasons to do this, like to avoid the "sawtooth" artifacts on things like hazard-stripe, etc, or to help avoid tiling on some organic materials, or to make sure all texels are used on a large texture that won't fit completely onto the brush.
  20. I like the idea of individual HUD elements only being visible when contextually relevant and otherwise fading off pretty quickly to leave the screen perfectly clean. All of the elements could still combine to give the impression of a visor but even the ammo would only be visible when the gun is actually in use, including initially. All elements could be invoked with a key, which keeps them active when the key is held and lasts maybe 3-4 seconds when tapped, but otherwise all fade away quickly.
  21. Great work on the video, keep 'em coming because this isn't necessarily just a nice resource for TDM mappers but level designers in general.
  22. I don't mean to sound offensive or condescending or anything, but maybe you could get into the habit of doodling a rough map onto a notepad (IRL).
  23. For now I have a couple of materials to offer, to see if they are worthy or not. Both of these I will put on (among other sites) http://www.opengameart.org under CC-BY. (*anyone is welcome to use these for whatever purpose) http://www.violationentertainment.com/temp/fnlltstnwcndrblckwll1.zip http://www.violationentertainment.com/temp/fnlltstnwhxyvrsalfeflr1.zip This is based on the cinderblock and hexagonal-tile floor you could find in UNATCO/MJ12-lab/Versalife. Again I'm yet another one working on a large project that is strongly influenced by the original Deus Ex and did actually consider using TDM at one point, but have since decided on a different engine that can handle much higher amounts of detail within large open environments with heavy use of batched LOD from the vertex buffer. That is not a criticism of TDM, it just is of idTech4, so I hope nobody will get twisted up into knots about that, it's just my personal decision. We still use Radiant so this community is very important, but we're using it in a different way. I would offer to do some mapping for this project too, and I might try a small UNATCO map, but to be honest, I think the technology is really outdated and I would rather spend my time on something that won't look like a mobile game. Again, I don't mean to sound offensive, just being objective about it. In my experience, you can't really get modern polycounts without the engine choking itself to death, and it's not far off what a modern smartphone can handle these days, polycount-wise. BFG edition may be different but without 'VBO-LOD' it's still not going to be something for posterity. I would really like to see this project take off but I doubt it is going to, unless 1) enough quality materials are hoarded for mappers to use, 2) mappers to actually use them to sprout some shots to show around, then(/while) 3) some very talented folks to get quality player models and v-weps cooking, which might be very hard to find. The quality stuff TDM had pretty early on in that regard is why I think we're all here right now, in my opinion. Also, I don't think salvaging (/vulturing) from other mods is the right way to go. Permission to use a material or 2 might be fine, but otherwise the project is at risk of becoming a junkyard. Bladeghost's PK4s have a lot of Doom3 assets in them, FYI. About more materials - I have a huge amount more, almost 5000 now, all can be used commercially, however I am a bit fuzzy on the license of some of them in regards to open distribution, such as from www.cgtextures.com, which I've used a lot for outsourcing. Also a lot from www.episcura.com which has been offline for a few weeks now and makes me a little worried. They might have been acquired, hopefully not by those sleazy TurboSquid slimeballs. I've tidied up a lot and made custom normalmaps (hand-made high-res heightmaps made with love, so NOT just typical photo-to-normal click-bang trash) and the other maps, but I am unsure about breaching the license agreement if they are to be put in some publicly accessible repository. On one hand it 'feels okay' and others have done it, but on the other hand I did actually _read_ the license agreement. Any advice concerning that, I would appreciate it. For the time being, if these 2 samples are good enough, I will provide more of what I am certain I can distribute, that I have not outsourced, created personally, or that was marked as public domain. Like I said, these will go on OGA as CC-BY so there will be no issues about anyone using them. Finally, my submission for possible titles (to vote on?) is "The Deus Mod" . . .
  24. Just curious if (the beginning of) this project is still happening? I'm still interested in being a part of it and still intend to focus on getting appropriate materials for mappers to use, just been too crazy-busy with other stuff to prepare anything just yet. I might do a small amount of mapping with it too, if it's still going. I'm interested in doing accurate reconstructions of the original DX starting with UNATCO HQ, but using more modern standards such as chamfering all those terrible infinitely sharp edges everywhere.
  25. Another idea that came to mind was to convert the PROC file to something that can be imported back, and I swear there was a way to do that, but I can't remember if it keeps the material headers and UVs enough in tact or not. Probably not. Never really needed to do this before, but I do remember it was possible as I compared how PROC files are carved up compared to idTech3 BSPs. __________________________ (edit): I believe "Noesis" was what I had used to do it:- http://richwhitehouse.com/index.php?content=inc_projects.php&showproject=91 __________________________ (edit): Ah yes, Noesis can convert PROC files to OBJ and keeps all material headers and UVs in tact. It separates by materials and Blender can easily separate further by "loose parts". Lovely.
×
×
  • Create New...