grapen

Members (Full)
  • Content count

    198
  • Joined

  • Last visited

  • Days Won

    5

grapen last won the day on January 14

grapen had the most liked content!

2 Followers

About grapen

  • Rank
    Regular
  • Birthday

Contact Methods

  • Steam
    grapen

Profile Information

  • Job
    Business Intelligence
  • Location
    Stockholm, Sweden

Recent Profile Visitors

533 profile views
  1. Yep. Without edited normals it looks pretty much like that gif. You can enable "ignore surface normals" on the prop in hammer, but that makes it look flat instead.
  2. Really curious about that skybox mesh you guys borrowed from Black Mesa. How many tris is that? Sorry for being sort of off topic, I'm working on something similar and still undecided as to what level of detail I want.
  3. I finally defeated VRAD. Slightly cheaper than our favourite Source tree, here for scale.
  4. Yeah smoothing tends to fuck over shading on props sometimes in Source. It has frustrated me quite a deal.
  5. Issue has been resolved. @Yanzl recompiled my model in Max/Maya(?) and got it to work. I had a look at his qc and found that he was using smd instead of dmx. I've been using dmx all this time thinking it was the newer, superior format. Tried to compile again using smd, still didn't work. Fak. Had a look at my rad file again and changed the backslash to a slash in my material path. It worked. What the fuck. I'm using backslashes in all my materials and qc's and that is working fine. Not in rad files apparently. So yeah, smd and slashes are required for forcetextureshadow. If any mod wants to rename the title of this thead to make it more Google-friendly, go ahead. I'd suggest [SOLVED] forcetextureshadow not working on custom prop, or something to that extent. None of the other results have an actual solution.
  6. Neither worked unfortunately, I'm at a total loss.
  7. Dirs: ...\csgo\models\de_scepter\scep_tree01.mdl ...\csgo\materials\models\de_scepter\scep_tree01branch.vtf ...\csgo\materials\models\de_scepter\scep_tree01branch.vmt .rad file: forcetextureshadow de_scepter\scep_tree01.mdl de_scepter\scep_windowglass01b 252 239 209 100 de_scepter\scep_windowglass01c 143 183 230 100 noshadow models\de_scepter\scep_grate01 Line 2, 3 and 4 are working just fine. So the rad file is being read, but the compiler refuse to ray-trace the alpha. The vtf is 1024, DXT5, eight bit alpha, so no funny stuff there I don't think? I found this thread with the same problem, but it didn't lead anywhere: https://tf2maps.net/threads/textureshadows-not-reading-my-lights-rad-file-correctly.26297/ Another thread that lead nowhere: https://tf2maps.net/threads/problems-with-textureshadows.24736/ Checked the poly count to make sure it wouldn't be that, but my tree is cheaper than Valve's urban tree.. Made a new model featuring just ONE branch, problem persist, definitely not polycount related, but could still be model related. Or material. Either of those probably.
  8. I very rarely experience toxicity at Master. At GE in CS:GO however...
  9. Let us know how angry you were before finally beating the (intended) second boss
  10. In my test map I have my tree and Valve's urban tree. In the console shot below we can see that Valve's alpha is being loaded, but not mine? My .rad command is: forcetextureshadow de_scepter\scep_tree01.mdl I might also add that the other lines in scepter.rad is being read and working as intended, it's just this line that doesn't seem to work. I've also tried backslash instead of slash for the path but that didn't matter at all.
  11. Yep done that to no effect Valve foliage typically requires "Ignore Surface Normals" set to YES since they don't have custom normals on the model itself. The rest of the settings can be default for the most part.
  12. Here's a shot of my WIP tree: From the left: Shadows ON and ignore surface normals OFF Shadows ON and ignore surface normals ON Shadows OFF and ignore surface normals OFF I've edited my surface normals (radial in blender), so the tree on the left is looking more realistic in terms of lighting. However as you can see, the shadows are just too thick. The tree trunk is literally black. The same shadow problem is happening on the ground, where it looks to be casting double shadows?! One that outlines the transparent branches/leaves and one large blurry mess that follows the edges. If I disable shadows, the blurry messy shadow disappears (see tree on the right), but that also makes the tree look flat. The interesting thing is Valve's trees are NOT doing this despite shadows turned ON. I've tried making sure I do exactly as Valve, but I'm obviously missing something critical. Here are the steps I've taken: Make sure my VMT use exactly the same parameters as Valve $alphatest "1" $alphatestreference "0.3" $nocull "1" (and some tree sway) Make sure my prop_statics have exactly the same settings Make sure I have forcetextureshadows on my model in my custom .rad (and that the path is correct) Check the console so that the .rad file gets read (it does) Any pointers? Is it the surface normals that are wrong? EDIT: Ok I managed to reduce the shadows on the actual tree by reducing the normal editing mix effect, however the blurry ground shadow remains a problem.
  13. Maybe, could be that the headcrabs and their mother just take Gordon for Combine. I mean the only difference in appearance is that Gordon is orange Sure, but it was interesting reading how that came to be. HL3 as an RTS or quick event shitshow.. Oh god..
  14. But the Xen creatures were good guys chased by the Combine :-( I guess slavery could be a thing though.
  15. Was thinking the same, that would be really cool. I would totally play an unofficial take on what happens to Freeman.