- Popular Post
Spooks
-
Posts
612 -
Joined
-
Last visited
-
Days Won
38
Posts posted by Spooks
-
-
There are two more lampshade textures, it would be nice if those could be converted to cubic for the future too.
-
1
-
-
I'd be paying with my time too, and that's far more precious.
-
Vampyr is now out, I am not a fan of third-person combat from a developer whose past history is bad teenager drama and a game I can't seem to recall right now, but I sure do like victorian london settings! Unfortunately, 50 dollars is too high of an admission ticket to just gawk at architectural pieces, so I'll just settle for the concept art from the game:
-
2
-
-
I specifically tested Patently Dangerous with Goldwell's Alchemy fix and there was EAX, so I would assume the EFX would work now, as well. The room settings were pretty overblown, though, for sure.
-
- Popular Post
- Popular Post
-
8
-
-
Hmm.
One last try:
https://www.dropbox.com/s/6g4wg1eaglgtzje/206beta_active_contacts.zip?dl=0
(uploaded to the same link)
OK, it's the very last thing I expected, which is ReShade. Short story: it's an external app, so warning sirens off, it's not a TDM problem.
Long story: this is very weird, because this bug only affects x64 versions of TDM + ReShade. 32bit+ReShade is not affected. Not as embarrassing a mistake to make, I think, since this is an extremely fringe case to encounter. I don't know what it is that causes this, perhaps it's because ReShade only uses an Opengl32.dll, but not a 64, but it still works, it only crashes on dmap... Oh well.
e: it seems updating the injector fixes the issue for x64 as well, so sorry for raising a ruckus
For the record, I have, like, half a dozen bugs like this in TDM/DR that I hold off reporting because the reproducibility is very inconsistent; I just got over-eager since I didn't want the final release to ship with a potentially big crash like that.-
3
-
-
No dice.
Edit: I've been able to dmap in 32bit now. It's why I was hesitant to report this yesterday, it's very inconsistent and I can't figure out what's causing it. Hold on till I run some more testing.
-
Neither have worked. I should also mention this is straight out of the menu, I don't need to be in-game. Also tested switching EFX, GLSL and FBO on/off, no difference.
e: short of any other ideas, whoever is willing to investigate can PM me within the next couple of hours and I'll give them the map to test.
-
I've been getting consistent crashing when dmapping in 2.06, 32/64, experimental features on or off. No problem when testmapping.
-
leather_chair_001 is defined in tdm_epi_shader.mtr, the leather chair was in 2.05 and I've used it in my WIPs. I don't know why AC1 might have a problem.
I've now done an update to the second release version from 2.05 rather than updating in my beta test folder, saw no problems. I can also confirm the checkmarks show, albeit they clip a bit into the black stroke of the selection.
-
Oh! I'm glad he finished that project, last I checked he was at week 8.
-
Well I've run into a snag and need to report it. chedap, I know you just fixed up the existing script, but this is related to smoothnig, so perhaps you, or someone else who works with Blender can offer any ideas on what's causing this.
This is what's happening to one of my models after exporting. Two are tiled together, and you can clearly see that the smoothing is going along the triangles' edges instead of being constant. (it looks the same in-game, but this is a screenshot Springheel took in Lightwave). In Blender, the problematic part looks just fine:
I tried all combinations of export options, recalculating the normals (of course), even made a custom plane inside Blender (since this is a .lwo import) and that exported with the same problem, too. So, it's got to be something with the exporter... .ase, in the meantime, has even normals.
-
Even after all this, the .ase still has just slightly better shading, but since the outputs of the exporter and Lightwave itself are now identical, seems safe to say it's as good as it gets.
Hello, thank you for this updated script. On this point, in particular, is this what you mean?
Right side is the .lwo, left is the .ase. I've overridden the materials to something more consistent than default textures for this model. It must be something to do with the edge or face normals, but I'm not knowledgeable enough to guess. It's a little irksome, but it's near invisible with real, detailed textures.
-
Hello, I want to discuss DR's texture tool and the way Radiant handles texture mapping in this topic. The texture tool is a window (Ctrl+Alt+T) where you can fine tune how a given texture gets mapped on a brush's face.
I have noticed that, oftentimes when selecting multiple sides of a brush, the unwrapped UV islands are placed way too far from each other. Not something you'd care about during regular mapping, but I think this is a problem in theory, which can become a problem in practice when exporting models from DR. This is actually my impetus for starting this thread, as I imported a DR model in Blender only to find its UV map being all over the place.
Here is an example of what I consider problematic. You can see that the face I've selected, behind the Surface Inspector, is already in the negative quadrant of the UV coord grid. Yet the surface inspector shows both horiz. and vert. shift to be at 0. Moreover, if I start changing those values with the arrow keys, the shifts will go up to 255 and then wrap back to zero, while the UV map will continue to scroll through the UV grid infinitely, instead of looping back to where it was.
Couple this with the arcane way in which the Paste Shader commands work, and you have situations where two brush faces might look aligned in 3D but have their UV maps be thousands of units apart in 2D.
Is there an explanation for why this works the way it does? Any way to make it better? Obviously, I'm not asking for DR to magically clamp all UV maps to the 0-1 UV space or unwrap brushes' sides like a modelling app would. It does, however, seem weird why there'd no apparent anchor for mapping faces to the UV space and they keep straying from the origin constantly.
-
r_useFBO 0
"Nvidia Hardware Detected. Forcing FBO"
Is this a part of the latest commit? This means that warp materials will be broken for anyone with Nvidia cards. At least uncheck http://bugs.thedarkmod.com/view.php?id=4684 as solved and shelve it for 2.07.
-
-
What makes the .ase exporter different then? As it happens, .ase files exported through DR don't have the same problem. Is this fundamentally a format restriction?
In the end, all I ask for is parity between the two export options, if not a mandatory one, then through some checkbox ("remove duplicate verts" in the .lwo export dialogue).
That bug report was started by BD and I don't know if this current fix works for his mapping workflow either.
-
No, both your screenshot and what I got in game are similar. You can see the models are not identical at the point where the bottle's neck joins the shoulder and the ring of polygons at top, representing the collar and lip. To me, that does not look smooth shaded.
I'm ignorant when it comes to automatic smoothing angles, but in my screenshot, the (single, continuous) patch curves up in increments of what can't be more than 30°, which IMO would be more than enough to get smoothed. Could this be the problem? Let me reiterate that exporting as .ase makes patchwork appear smooth as it should be.
-
I request http://bugs.thedarkmod.com/view.php?id=4750 be reopened. I tried with pre4 and the now-released final of 2.6.0, it seems nothing has changed.
Left is .lwo exported with the new DR, right is .ase exported with the old version. I tried exporting both from .ase -> .lwo and brushwork/patches -> .lwo. Same result.
EDIT: For control, I have just tested the model greebo tested with, in the bug's notes -- bottle02.lwo. Same result, the exported .lwo (which in this case is .lwo -> .lwo) still has non-smoothed edges.
-
Looks like I got on this one a little late, I don't think I'll have any time to do any substantial testing before release. By no means wait for me or anything! FWIW thank you very much for fixing the bugs in this release in addition to the one or two feature requests I posted. I have a mounting collection of .ase-exported models, so the fixed .lwo model exporter will help me greatly in cutting down the size of my WIP.
-
I must one up Goldwell. This is actually the oldest screenshot I have in my folder, from 2015:
And for an actual bug, here's the second oldest screenshot I've kept, from 2016:
The rats were both alive, which made their jenga tower formation incredibly impressive, as they kept balance perfectly as they walked around.
-
1
-
-
Bow draw speed, is it me or does it take much longer to fully draw back the bow compared to 2.05..?
You may also have gotten the wrong impressions from FMs like Northdale ACT I and Volta II, if you've played them recently. They have their bow speed draw animations increased by the authors. Me, I think it's the same.
-
Finished it a couple of days ago, brilliant mission! Reminds me why I'll never pass a Goldwell FM up. A dozen tiny details ensure this remains a memorable experience. I got about 2 out of 7 secrets, I thought the main part of the mission did not overstay its welcome and I enjoyed the varied locations you explore. Only problem was, paradoxically, that they could've been fleshed out way more. I got excited when entering the Thieves' Guild and the rooftops, but they were over before I knew it. Ah well, I suppose pacing trumps all. Best of all, it's not droll like much else of what be on offer in our selection of FMs. It's snappy and adventure-y, a refreshing change of pace from all the grimdark missions already published.
-
1
-
So, what are you working on right now?
in TDM Editors Guild
Posted
Hey, friends, here's an update for you. I've wanted to post this since last week but never could find the time. I've shown various pieces of content over the past months without a lot of explanation of what's from where and when you might expect a real release from me.
I started a speedbuild shortly before the release of 2.06, not really expecting to meet the release window. Still, I've made some good progress for 35 hours of mapping and I intend to stick through this one to its completion. I'm lucky to get 4 hours of free time a day nowadays, so progress is unfortunately slow, but know that I am still dedicating a large portion of my time to TDM regardless. I currently do not have screenshots of this speedbuild to share with you as I am in the trenches of the environment pass stage, where everything is half-finished. I'm aiming for, at most, 100 hours before I take this map to beta testing, so let's just cross our fingers and hope for the best.
I have two, bigger maps on the backburner, which are a part of a campaign, and another one-off which I don't plan on touching until those are done. If you enjoyed the background for the new TDM site design or the 2.06 release image, guess what? They're from one of those maps! I provided some screenshots to Springheel and I am really happy that he gracefully chose to feature them. It is my hope that, if nothing else, my snazzy scenes spark up some interest for the mod from outside viewers. There is an additional screenshot in the Media tab of the website that is also by me, if you haven't been there I recommend checking it out.