Here's all 5 models ingame (yes that includes the original one you made) I like the winter skin and am using these in a map i'm reworking/finishing for someone so I hope you don't mind the tweak. All I did was rework/combine the newest pine_winter.vmt texture with the older one and voila, good trunks, new models, and my schmexy old snow branches.. If you want the file, let me know, and if you are still working on the Winter Skin, I look forward to the final version.
~1200 verts, compared to ~900 for the no-snow one. But this one only got snow on top of branches where it "should" accumulate. Up close they will always look like "lol tv snow" as someone put it. $translucent materials has a tendency to give z-fighting issues, and the $alphatest materials are on or off, no gradual blending. So this is probably the best way to go about it. Still playing around with this so I won't upload this version atm, got a few more ideas I wan't to try out. Still need to do something about the bases too... doesn't look all that good when they just pop out of the ground like that. In a perfect world I'd have an animation of the base sliding up the trunk, that could be set by a parameter in Hammer. But I don't think that would work.
maybe you're a bit confused about $alphatest: $alphatest allows partial transparency, $alpha specifies a certain alpha value to be applied over the whole texture $alphatest is lower quality than $translucent but it's definitely what you want if you're using an alpha channel nevermind i'm dumb Edit: personally I think, while yours look more logical, rappe, bitchslap's evenly coated snow looks better for ingame use (mipmap problems aside). A second skin with snow on it is more suitable than an alternate model with extra geometry, too.
Valve dev wiki says otherwise. Or maybe I'm just misunderstanding. I won't argue with Empires communitys Mr Material Man... but my own testing with this shows what's on there to be true. And yes, ofcourse a second skin is better in all aspects except one. It looks worse no matter what. Edit: I just saw this. See the discussion page. Now I understand why the EP2 trees look so much better up close. This shall have to be investomagated in the morrow!
hmmm you're right, come to think of it I'm not sure why I was convinced $alphatest worked for alpha gradients. No experience with $distancealpha though
well mine was just slapped together so i could use a winter skin again on all the models, to me you don't remove the partly broken until the fixed is added, unless the broken is preventing the latter fix, but that's just my approach. Would love to help more on this but i think Rappmo's got a better grasp on the details than I currently and two chefs can merely cause probs. Imho, if you could use the texture i'm using for pine_winter.vmt then work on adding LOD or Mipmap to help the fps at distance then it would be done imo. It's already a huge improvement over whats ingame and whats out there.
IIRC EP2 trees also just use $alphatest and not this fancy $distancealpha. Idea: unpack all the TF2 .VMT crap (perhaps EP2 stuff, too) and search them for $distancealpha, see if there are examples we could learn from
Yeah I noticed that they seem to use the bog standard alpha as well. This alphadistance mojo does apparently not work with third party tools either so... meh. Besides, it seems it would be mostly useful for making smooth GUIs for any resolution without using a shitload of redundant textures. New version of the trees on the derpbox in the sig below, where the following is new since last time: 2k texture Ep2's Pine04 uses a 2k so in an attempt to get more details in mine I upped it. Succeded on the branches, not so much on the trunk. Oh well. Tweaked mesh Base got some love to lessen hexagonal look. Winter version Since Bitchslap keeps showing these in here, I might as well make a proper version. Cheap skybox billboards As per flashe's request. These are CHEAP though, intended for far skybox. New filestructure to comply with Bitchslaps standards Blender SMD tools don't export materials proper, so I have to go through each SMD in notepad afterwards and point em right. A bitch to rename all the shiz, but now it's done. Edit: I just got animation to export properly, great success! Is this something we want in? An idle sway anim a la Orex? I haven't gotten this to work proper in Hammer myself, but I still have fond memories of the first Ghost Recon game which featured a subtle sway to it's pine forests.
Are you exporting directly from blender? Have not touched the source exporter for blender in awhile, but I remember it being a pain in the ass to use. which also brings me to another subject, how hard would it be to make destructible trees?
Yep, straight from Blender. It exports SMDs where all the tris are UV mapped to a texture named as the exported object in Blender. When you got four trees and all their lods in one scene, this gets troublesome as Blender does not allow multiple objects to share names. Thus the need for some Notepad++ elbowgrease. Destructible trees are something I've thought of since I began this journey into the depths of arboreal insanity. I have not looked that far into it yet though. Edit: Looks like they would have to be either 100% clientside (Bad) or something other than physics based (What?). So idno if its possible. Valve dev wiki on Physics entities client- /serverside
With prerendered physics you might be able to do it. Even if it wouldn't be worth fully implementing, it's still a cool idea and worth looking into IMO.
thanks for winter skin rappmo, will check it out soon. as far as destructible goes, it is possible as they just added gibs to ML and MG turret which are animated models and not brushes afaik. so it should be addable.
The orex sway was sloppy. Trunks shouldn't sway unless the collision models sway, and this game puts enough stress on the server without tree collision models dancing a jig. If you're thinking the trees would have to be clientside, that's wrong. Only the gibs that result from their breaking would be clientside (the same as walls atm). It might even be possible to make gibs serverside, if that was really important... But I don't think large trees, such as firs, should be breakable. There's going to be a lot of them, so it's better to have them as static trees, and they're thick enough that they'd be expected to stop a rampaging CV.
isnt it basically just replacing the model with its broken parts and apply physics? similar to walls, you have full wall-piece models and gibs ...
It would be pretty sweet is all I'm saying. Herp Derp! I'mma chargin mah lazor! Kekeke heavyrush through forrest! The problem is that the gibs would have to be large, and if they are clientside we end up with weird stuff like different visual blocking for all clients. Making the gibs smaller would just look weird. Gameplay wise, Infantry would no longer be able to take refuge in forrests. It's just something that crossed my mind while making them. I'm sure time is better spent elsewhere.
Rappe, i started experimenting with making a bark texture, but then i saw that the pine model you showed on page 3 already has a different texture from the models from the downloadlink in your signature. Have you by any chance progressed further then those you put online ? Anyway, making a bark texture from pictures is relatively easy as it turns out, but making the bottom part with the moss etc will need some more practicing on my part. Also the changed texture would require to uvwrap the model again to fit, and have the texture repeated more often (it's seamless) for more detail on the model. The biggest problem being adepting the color of the trunk to the color of the branches in the texture, as my bark is a lot lighter; and i'd rather find a way to make the branches lighter than the trunk darker, which i have no idea how to do without affecting the the pine needles. http://dl.dropbox.com/u/234836/Modelling/comparison.jpg If you have a new texture already however nothing of this is necessary. Also one thing i noticed, the models from you signature cover all tree models i used in chain with the exception of the big one. It would be nice if you could scale up your standard pine model to about that size as well, and i'd be able to just swap all EP2 models with yours.
Nice Silk! Making it from photos should be superior to anything I can paint. The whole point being to make these 100% our own I haven't wanted to use any web pictures, regardless of license, and there is too much snow around here atm to go out and grab some myself. As for texture versions, the last change was last time when I upped it to 2048 and played about with some sharpening. Other than that, the trunk texture has not changed all that much since first version I uploaded I think. I unwrapped it much like the Ep2 tree. With the trunk eating up the left half of the texture and the rest of the bits on what's left. rappmo_pine_TEXTURE.rar I overlayed the UVs on a separate layer on that one if you want to have a peek. Edit: Hurr. I just noticed a Derp I did. Last versions material vmts does not point to the new custom folder. Will fix that momentarily. Edit2: New upload. Repointed the VMTs to the new folder.
Thanks btw do you know if it's possible to see how the ep2 trees are unwrapped? The resolution kept looking low, eventhough it's now at the size of the ep2 models, so i checked the bark on those and apparantly valve cheated by having the two halfs of the trunk share the same uv space making it possible to double the uv space. Because they made that edge seamless and you can't possibly see the two halfs of the model at the same time, the models have twice the detail for the same performance with no graphical downsides. I think i could make a texture do that if it were all straight angles. And yes, i had noticed and corrected the vmt