why are some models invisable?

[commando]

hey all...

i have some wierd problem...

i made a quick room for half life 2.... i added some boxes and some junk...and a crowbar.

Now when i went into play it. the crowbar was shown, but the boxes and junk were invisable?

why is this? can someone please help me?

 

[The Dark Elf]

hey all...

i have some wierd problem...

i made a quick room for half life 2.... i added some boxes and some junk...and a crowbar.

Now when i went into play it. the crowbar was shown, but the boxes and junk were invisable?

why is this? can someone please help me?

Did you add them correctly?

check the compile log and check the console when its loaded, it might be trying to load certain objects as the wrong kind of prop, causing them not to display.

 

[brisck1]

I just experienced something similar when I added a prop_physics entity using the wasteland radiator.mdl. I could hear it hit the ground when starting my map, but when I look around it's nowhere to be seen!

 

[commando]

same is happening to me man. i think it might be due to copy/pasting but hmmm im starting to see some but some are still invisable. going to quick check

 

[The Dark Elf]

Sure your not setting them to appear only at very close distances? Many have options now on the distance you can see them at and at how far they begin to fade out to nothing to help speed things up.

 

[brisck1]

I managed to fix it by checking "sleep" option it the properties. This makes it static until any force it applied to it

 

[commando]

hmm. it is very annoying!

no it just doesn't appear no matter wat!

it happens to all objects...but then some do work :S it is very strange.

ie i make a box and it shows. i make another and it doesnt same with a barrel and a bottle. and maybe others!

 

[polypod]

i just read this about prop_physics:
"If the model used by the prop is configured to be used as a prop_dynamic (i.e. it should not be physically simulated) then it CANNOT be used as a prop_physics. Upon level load it will display a warning in the console and remove itself. Use a prop_dynamic instead."

 

[commando]

ooo so you can make all objects prop_phsics but it doesn't mean they will show up.

nice one poly you the man thanks alot.

i will test this

 

[The Dark Elf]

Don't use another type of prop to get past something too much

-- taken from the VERC site --

Characteristics of prop_detail:

* Can have 10's of thousands of them in a level.
* Can be .MDLs or sprites. Sprites are much faster to render than .MDLs.
* Can be placed inside the Hammer editor or by adding a material property %detailtype to a .vmt file which causes vbsp to automatically generate detail props over particular materials (described below).
* Can never collide with them.
* Are lit with a constant color (for optimization purposes).
* Don’t affect lightmaps in the world.
* Automatically fade out when they exceed a particular distance from the player (controlled by the console variables cl_detaildist and cl_detailfade).
* Will probably not ever be rendered on low-end hardware.
* Must use models compiled with $staticprop in their .qc file.
* Have no network overhead + very low memory usage.
* Is not a real entity, has no inputs or outputs.
* May not have animations.
* Can not be hierarchically attached to other entities.
* From a visibility standpoint, they are assumed to be points.

Characteristics of prop_static:

* Can have thousands of them in a level.
* Can be placed inside the Hammer editor.
* Can have collision associated with them.
* Will affect lightmaps in the world – can cast lightmap shadows.
* Will be vertex lit like standard studio models.
* Will use LOD system.
* User selectable as to whether the prop is rendered on low end hardware.
* Fade distances can be set in Hammer editor.
* Must use models compiled with $staticprop in their .qc file.
* Have no network overhead + very low memory usage.
* Is not a real entity, has no inputs or outputs.
* May not have animations or joints.
* Can not be hierarchically attached to other entities.
* Optimal from a visibility standpoint, it uses the convex hull of the object.

Characteristics of prop_dynamic:

* Can have hundreds of them in a level.
* Can be placed inside the Hammer editor.
* Can have collision associated with them.
* Will not affect lightmaps in the world, but they do cast dynamic shadows.
* Will be vertex lit like standard studio models.
* Will use LOD system.
* Will exist on low-end hardware.
* Fade distances can be set in Hammer editor.
* May use models that are not compiled with $staticprop.
* May have animations.
* Have low (but non-zero) network overhead + higher memory usage (as much as any entity).
* Is a real entity with inputs and outputs.
* Can be hierarchically attached to other entities.
* Optimal from a visibility standpoint, it uses the convex hull of the object.
* From a visibility standpoint, they are assumed to be boxes.

Characteristics of prop_physics:

* Can have tens to hundreds of them in a level, depending on complexity.
* Can be placed inside the Hammer editor.
* Must have collision associated with them.
* Will not affect lightmaps in the world, but they do cast dynamic shadows.
* Will be vertex lit like standard studio models.
* Will use LOD system.
* Fade distances can be set in Hammer editor.
* Are faded earlier on low-end hardware unless settings changed.
* May use models that are not compiled with $staticprop.
* May have animations.
* Have low (but non-zero) network overhead + higher memory usage (as much as any entity).
* Is a real entity with inputs and outputs.
* Can not be directly hierarchically attached to other entities.
* Can be constrained to other entities by various physics constraints entities.
* Optimal from a visibility standpoint, it uses the convex hull of the object.
* From a visibility standpoint, they are assumed to be boxes.
* Additional characteristics?

Characteristics of prop_ragdoll:

* Same as prop_physics, but can use skeletons for ragdoll physics.
* Has very high network overhead.


----

If you make too many things as another type of prop, you might find you can no longer make any more of that type when you need it.