See dissapearing trees in maps like dod_glider and dod_dirtydozen as you move around corners???

That's because the origin of the model is being blocked by the wall. To temporarily solve this problem, you might need to reposition offset the model (make your own version) that is better suited for your map. This results in larger file sizes and lack of consistency as every map can't reuse the stock content from DoD.

My suggestion is to code the engine to calculate VIS based on an env_model's resultant bounding box, not it's origin. Unforunately, entity visiblity set seems to calculate stuff based on the origin of entities......not the bounding box. This might be hard to code ( ie. bounding box visibility detection). Then again, if you managed to code bounding box visilbity detection for env_model, (does player models and monsters do it this way??) then it would be good. My suggestion is to create a mosnter_generic-similar entity that can work in multiplayer and not form this vortex sprite effect bug..... , and the engine will use the model's bounding box to determine visiblity, hopefully.

This would be good, but don't expect such changes while DoD gets to his end (in 1.2).

Much easier it would be to create 2 versions of such models. First with origin in lower part, second, second - with origin at higher point. This needs to be done only for some taller models like trees, etc. Then mapper can use right model, according to near 'environment'.

Yea...the arc/xerent tree has a low origin but the kami tree does not...so that one tree at the bottom of the hill in glider was replaced w/the high-origin kami tree...I wish all modelers made models with three origins...low...middle...high. It's especially hard when we try and put stuff in rubble...like the flo bathroom stuff or the DoD models that have damaged sub-groups...we have to sometimes place them in non-world brushes like func_walls and the like so the origin can be "seen" by the engine

also worth noting...

the lovely Barrel model (woodbarrel1.mdl or something) we made has that problem too, not to mention the pine tree model.

if someone was really keen they'd post a list in here of which models have this issue, but that's a lot of work.

excellent post, Glidias.

yea, with dirtydozen, the trees didnt show up until u were at the same level, so i moved the origin of the models up and it was better, luckerly the origin was a quarter way up the tree.

if modelers made the origin in the middle of the model it would pretty much take away this problem, not that i blame modelers or anything.

They should at least make it so you can set the the origin to an entitiy so when you get a problem like vis blocking your model when it should be visable or the model being shadowed then it should not be you can just tie the model to an entity and put that entitiy where you want the model origin to be and it will act as the light and vis for the model

OMG FD- ur right about the submodels thing. I hate the submodels- they're impossible to use in Hammer!

I had to decompile the submodels to get an idea of where they'd be. Why didn't the DOD team just make the submodles as (dum dum dum) OTHER models!! It would make mappers lives so much easier, and as for the "saving space" argument, I know that there are repeated models in the mapmodels folder!!!!!!!!!

You can display submodels with HL model viewer. WHy decompile them?

Submodels save texture memory as the submodels can all share the same texture .bmps within the .mdl. This reduces the number of textures used in the map. If you had a unique .mdl each time, each .mdl will basically have to load their own unique texture .bmps, thus adding to the texture memory of the map. Submodels are useful for ensuring a bunch of similar models share the same texture .bmps thus it will be less of a memory hog this way. Also, submodels can also share the same animation sequences! Extremely useful! Thus, if you've have a bunch of .mdls that share skins and/or animation sequences, sub models is the way!!

I'm not sure though, but is there a way to compile a modelT.mdl and various models model1.mdl, model2.mdl, model3.mdl and all these models depend on modelT.mdl for the textures?? So far, i only know how to do a model1.mdl and model1T.mdl compilage, which isn't very useful. I wouldn't mind a modelT.mdl that is shared among various .mdls. Is that possible?

But i still don't mind submodels. In fact, i like it. If only you could display submodels in Hammer....

Glid-man is 100% correct...all we really need is the ability to see the sub-groups in hammer...I think it's more a "I don't have time to mess with HL1.X hammer" as to why we don;t have that option yet...it's not theroetically impossible...it's just the dev team has no time to actually work on this one specific issue.

I imagine that support for hammer after HL2 arrives will become either non-existant or we'll have to find someone on the outside who can code.

Yeah I understand what u say Glidas, I tried that, but try placing a model with a submodel where you want it, with the invisible func_wall around it. Also, submodels go through walls and stuff.

Still, things are better than when we didn't have model viewing in Hammer.

The PIPE and SANDBAGS models are prime examples of absolute arsery to do!

(see pic for sandbags).

I imagine that in HL2, the models and textures will be separate (a la Quake 2-3), so the need for submodels should no longer exist hopefully; this should also mean that player models should have region specific skins (the much wanted Afrika Korps & 8th Army).