Model leakage with brushes.

[Hipshot]

Sometimes, not always, I get leaks when a models origin touches the same vertical/horizontal line as a solid structure-brush. However, they are reported like this Entity 79, Brush 0: Entity leaked, but do I need to care about them, is it considered by map2 as a real leak and would it give me the same problems as for say a hole in the hull? I'm using _alot_ of ases these days and I have probably ~70 models that touches structure brushes over the map, lamps etc.

[zZCastleZz]

just to be safe I would fix it.

Too often I find even when you think it doesn't matter it has some oddball effect that might not even seem to be related at all. Like all of a sudden bots OR enemy AI all where sombreros and fart the national anthem. You know, things that only a coder could try to explain.

Even if its a warning try to avoid letting it sit around. If you have to ask the question then the default answer is to just fix it.

good luck!

[^misantropia^]

Your model is (should be) detail so it should have zero impact on VIS. I suspect q3map2 complains because it detects intersecting brushes, which are normally bad but not in this case.

[Shallow]

I agree with the llama. Entity leak messages on models usually don't mean anything. Unless you are seeing something weird in game, ignore it.

[zZCastleZz]

Your model is (should be) detail so it should have zero impact on VIS. I suspect q3map2 complains because it detects intersecting brushes, which are normally bad but not in this case.

Zero effect on vis?

Even detail brushes need to be with in a zone or leaf node to know when they can or cannot be seen by the player. If you do showtris the polys on the models do eventually cull when they are blocked by brush geometry right?

wouldn't you think that at least to some extent there is a chance that a ASE model might run into a situation where it doesn't know what leaf node it is within thus making it render even when it shouldn't be?

Maybe I'm misunderstanding the problem too..

[Shallow]

IIRC after the inital BSP phase converts the model meshes into drawsurfs, they are placed in leaves based on where the triangles are, just like drawsurfs from any other surface.

Seriously, it's an annoying popup that can be ignored. It's frequently necessary to place some things this way, e.g. unless they're on a perfectly flat surface Wolfenstein tree models need their origin buried to avoid having the bottom edges on the trunk showing.

[Kat]

Which is why when making and using models people should make allowance for the fact that models will be buried ;o).

Personally, I wouldn't blanket ignore the message because they do occasionally do weird things during/after compiling when you do; they don't show up, don't get lit properly, missing collision, missing faces, and that's not even touching on bot aas problems (assuming this is for Q3 that is), try comiling an AAS with a 'broken' entity in a map :icon27:

[zZCastleZz]

Wolfenstein tree models need their origin buried to avoid having the bottom edges on the trunk showing.

Makes sense. Though in the case of the Wallenstein trees the terrain mesh was made of detail brushes and thus the trees origin was fully within a valid leaf node. Wolfenstein used the Quake terrain stuff IIRC. right?

But yeah if the ase models triangles are individually stored within in leaf nodes then it shouldn't matter one bit at all where the origin of the model is located. That is pretty damn slick design.. Ydnar ftw.. IIRC he is the one who set the tools up to work that way..

Though I wonder what the list of objects looks like with a fairly high poly model in a scene with a lot of leaf nodes lol..

For some reason I'm still thinking in terms of ASE models in doom 3 or quake 4 where the origin of the model is still important for occlusion culling since the portal system works so differently than the older bsp method. Most models aren't ever set to be inlined because a lot of people dont build models that full take advantage of that feature.

I might be one of the only people on the planet who likes the older bsp methods vs the highly limited simple portal culling methodology.
TOO EACH HIS OWN!!!!!
Or just use Unreal engine since its been doing both methods together for years.. lol..

Which is why when making and using models people should make allowance for the fact that models will be buried ;o).

hehe All artists who build tree models with the origin directly at the bottom of the model should be forced to populate a terrain level with nothing but structural brushes with said model LOL.. Also compile time is part of the punishment. lol

[^misantropia^]

Zero effect on vis?

Yep. VIS data is calculated by taking all the structural brushes, extracting the volumes they enclose and determining which volumes are visible to each other. Anything detail doesn't come into play in this stage of the compilation.

wouldn't you think that at least to some extent there is a chance that a ASE model might run into a situation where it doesn't know what leaf node it is within thus making it render even when it shouldn't be?

No. A model or a brush always has only one origin[1] and that origin is always within a volume (unless your map is leaking, but that's a corner case obviously).

[1] For a brush, that's not entirely true. But it does hold for the vertexes it is made of.

[Foo]

wouldn't you think that at least to some extent there is a chance that a ASE model might run into a situation where it doesn't know what leaf node it is within thus making it render even when it shouldn't be?

I was thinking something similar. The warning could be due to potential problems with placement and visibility of the model itself, rather than it causing a problem with the vis process itself.

If models are culled if they lie outside the boundary of the world hull, then a model with its origin resting directly on the edge of the hull is perhaps at risk of being culled in some situations?

Not sure if you could fix this by tweaking the origin point for the models, or sinking the hull behind the model.... If you really can't see any unexpected behaviour from any of the models then I guess leave it...[/quote]

[zZCastleZz]

Yep. VIS data is calculated by taking all the structural brushes, extracting the volumes they enclose and determining which volumes are visible to each other. Anything detail doesn't come into play in this stage of the compilation.

Yes
I was referring more or less to the entire process from compile to in engine running the level though. They might not change leaf volumes or portals since they are detail brushes but they do need to be told where and when to be drawn. like "what leaf node am I inside of right now?"

for example around the same time that the compile tools determine which volumes are visible to each other they are also figuring out what brush surfaces and models are stored with in the leafs.. lol my point is rather silly because I IMO it isn't zero effect because I feel more like it is 0.1% effect on the compile process itself.

You are correct detail brushes and ASE models dont change leaf nodes, portals or anything of that nature.

[zZCastleZz]

I was thinking something similar. The warning could be due to potential problems with placement and visibility of the model itself, rather than it causing a problem with the vis process itself.

If models are culled if they lie outside the boundary of the world hull, then a model with its origin resting directly on the edge of the hull is perhaps at risk of being culled in some situations?

Hey Foo I have two kittens that look exactly like your avatar LOL.

From the above description to answer your question or point, the way quake 3 is being told to handle the ASE models in the above example is literally to break up the models polys and store them individually(or grouped) and place them with in leaf nodes in the level. If this is true then the origin of the ASE could possible not be important at all for the engine itself come rendering time.

Only catch I can see for this method is that your tri-stripping would suffer depending on BSP complexity????

[obsidian]

Q3Map2 complains because you have an entity intersecting structural brushes, so it considers the entity to be floating out in the void - thus the leak error.

Which is why when making and using models people should make allowance for the fact that models will be buried.

Best case scenario, yes. If possible you should allow for this.

I'm not sure if this will cause any problems down the road, but personally, I would just spend the 10 seconds per model and just move the origin a few units and re-save. Really, it's not that much work.