Prop's footprint in LE is too big

[TheMurderousCricket 5,104]

Hey Guys,

A quick question. I'm trying to make myself some forest lots and am using some of girafe's veggies as well as SimFox's trees.

The problem I have is that when I want to use the prop family I have created out of these authors' models, I am getting a really big prop footprint which "depletes" the free area around the props pretty quickly.

It's not an issue in and on itself. However, as I have already learned some time ago, I won't be able to squeeze any MMPs onto this lot when I actually plop it in-game.

Is it, like, the LE takes up the size of the largest prop present in the prop family and uses that as a reference for all other objects? Or what is the mechanism? Is there any way to reduce the size of the prop's footprint in LE?

 

[rivit 3,402]

The size that LE works with is an attribute of the prop - called Occupant Size (X,Y,Z) .

If that's too big one can 'sucker' LE into believing its smaller by editing that in Reader. It still needs to be reasonable or you may get props interfering with one another (LODs intersect), and a Family should all be the same size (fit the same space on a lot).

In your example the Occupant Size looks quite a lot bigger than the props really are. You can check what it really is by looking at the Verts tab of the S3D Model which gives the dimensions of the model per vertex.

[TheMurderousCricket 5,104]

Thanks for chiming in @rivit.

On 20.08.2022 at 2:34 AM, rivit said:

In your example the Occupant Size looks quite a lot bigger than the props really are. You can check what it really is by looking at the Verts tab of the S3D Model which gives the dimensions of the model per vertex.

Indeed, SimFox's objects always seemed huge to me. You are right - I checked the values and they can indeed be reduced a little.

On 20.08.2022 at 2:34 AM, rivit said:

a Family should all be the same size

Why is that? Is there anything wrong with having slightly different sizes for objects in the family? Say, 2 - 3 meters...?

On 20.08.2022 at 2:34 AM, rivit said:

It still needs to be reasonable or you may get props interfering with one another (LODs intersect)

I think I made a "reasonable" change which I tested on the Alnus model.

The Alnus on the left is the one with the edited "bounding box" which is smaller than what has been written in the original .dat. The one on the right is the original, large tree. It seems that the rendering and perspective is correct for both objects and no visible differences are present. Objects standing farther away (behind) the Alnus are correctly represented too.

[rivit 3,402]

2 hours ago, TheMurderousCricket said:

Why is that? Is there anything wrong with having slightly different sizes for objects in the family? Say, 2 - 3 meters...?

The whole concept of family is that items that are related in theme and size can be used interchangeably (randomly, by the game engine) without consequences, so that multiple combinations can be created. The bounding box of the family determines how close you can place any of them to other things. If for example the bounding box per family member can vary by 2-3m then the family needs to be placed with the largest space it can be for all of them. If they are given that same occupant size you don't need to remember that.  Its possible (as you mentioned in your original post) that LE does this for you but to be frank I've never tested that proposition.  

Your examples seem to have worked out well.

[TheMurderousCricket 5,104]

18 hours ago, rivit said:

Your examples seem to have worked out well.

I made another test placing some trees in front of the alnus tree. It looks kind of weird this time though...

I have to say, I cranked the occupant size down even more, just to stress-test... 

As you can see in the following picture, the seasonal birches' tops seem to be chipped away by the alnus. Interestingly, this happens for both the "shrinked" tree and the default one. Again, no visible difference in the object's rendering can be seen despite significantly different occupant size...

Hm... the fact is that girafe's seasonal trees have very small occupant size which is exactly 1 meter! Perhaps this is the problem now and not the size of SimFox's trees? 

[TheMurderousCricket 5,104]

Interestingly, I am still unable to shove any objects around the alnus, even when the occupant size is smaller... No use in editing that I gues...

EDIT:

Wow! Here's a really interesting experiment!

I made a little test lot in LE and then tried the edited and unedited alnus instances in the game's proving grounds.

It turned out that editing the occupant size to a smaller value has actually made the object worse in terms of the space available around it! 

In order to test the workable space around my flora-as-props, I simply drew a continuous line of MMPs from as close to the trees as I could. It turned out that the tree on the left, which has a larger occupant size allows MMPs closer to itself than the tree which has smaller occupant size!

 

@Cyclone Boom - I hope you don't mind putting you on the spot. Have you ever explored the "occupant size" property with Cori or on your own? Why decreasing it actually makes the exclusion zone around an object greater?  

[Cyclone Boom 17,031]

9 hours ago, TheMurderousCricket said:

@Cyclone Boom - I hope you don't mind putting you on the spot. Have you ever explored the "occupant size" property with Cori or on your own? Why decreasing it actually makes the exclusion zone around an object greater?  

No worries to @ mention me.

It's an interesting property is the Occupant Size and I've had a little play around it, but not actual measured testing as you've done. Good job there with experimenting around with the sizes to tweak and test. One thing I recall is if setting the size larger than the model itself, it can cause Immortal Lot Syndrome to occur. This is when the model is still visible even after bulldozing, since it overhangs and intrudes into neighbouring lots. I believe this only occurs with buildings and not props on a lot.

That's quite unexpected how a smaller size prevents the MMPs from being added closer. I'm curious too whether there's a reason for this. It seems like it couldn't just be random, as you've reduced it down and the expected result would be allowing more room. It does the opposite though weirdly enough.

[TheMurderousCricket 5,104]

It gets even weirder...

Here's another example. I tried to check the same process with a different model to perhaps see if there is anything wrong with the model itself. I chose grfe's winter birch.

I have created a separate .dat in which I changed the occupant size property again, only to a somewhat larger value this time. Then I ran the game and tried to plop as many MMPs around the objects as I possibly could. The results are staggering to say the least...

The tree on the left is the girafe's original. The one on the right is the one with edited properties. I have been completely unable to use MMPs in the bottom-right area of the lot I created! 

This makes me wonder if it's perhaps the problem with iLives reader rather than the object itself. I'm using version 0.9.3 and it has worked correctly up until now...

EDIT:

AWWW NUTS!!

I think I just realized what the problem is! Hold on... 

[TheMurderousCricket 5,104]

Ok, so it dawned upon me, that the unploppable area from the image above is actually the building footprint of the edited lot.  This, of course, was preventing any MMPs from being planted within the building's clearance. This is also why I drew an incorrect conclusion that shrinking the occupant size has an opposite effect to what it should be - it was the "fault" of the building placeholder all the way...

 

Digging through the LE and girafe's trees however, I came to a conclusion that the, otherwise beautiful, seasonal prop trees that this user provided are fundamentally flawed as far as the prop occupant size is concerned...

Each of the birches, ashes, poplars (you name it) props that are a part of girafe's bundles have alarmingly small occupant sizes. All of them are 1x1x1 meter.  The vertex data in LE, however, indicates much larger true sizes.

It is not just a matter of numbers. It actually has some very detrimental effects to girafe's trees representation when they are placed in front of other props - the very problem that @rivit has mentioned about props interfering with one another. Girafe's props look as if they were in front of an object while, in truth, they stand obviously behind it. Consider the following example...

 

I believe it could be a good idea to actually contact Girafe to make amendments to his/her tree sets... I don't know if they (Girafe) are actually here on Simtropolis though. There is a user which goes by the name "Girafe" and has even received an award for a best non-building innovation (seasonal trees, right?) but I'm not sure if this is the right person!

Anyway, what do you guys think? Should we link him/her to this discussion? As far as I can tell, the objects definitely need some face-lifting if they look like that!

[rivit 3,402]

It may well be useful to understand from Girafe what their philosophy of small occupant sizes means to them - there will be a reason that we need to account for.

However, I think it also important to keep in mind that Girafe's trees have seen very widespread use and are a favoured replacement for Maxis trees and so having changes made to them after so many years will be unlikely (a) because of the scope and (b) because of potential side-effects. Also,  to my knowledge, no-one has asserted that they are unplaceable or unusable because of their occupant size. Lotters will always do a visual check of the result and on that basis place them accordingly.

So while you have demonstrated that issues can occur, they are avoidable, and there is probably little evidence that they are out there in the wild, so to speak. 

[SIM-ple Jack 17,450]

13 minutes ago, rivit said:

It may well be useful to understand from Girafe what their philosophy of small occupant sizes means to them - there will be a reason that we need to account for.

However, I think it also important to keep in mind that Girafe's trees have seen very widespread use and are a favoured replacement for Maxis trees and so having changes made to them after so many years will be unlikely (a) because of the scope and (b) because of potential side-effects. Also,  to my knowledge, no-one has asserted that they are unplaceable or unusable because of their occupant size. Lotters will always do a visual check of the result and on that basis place them accordingly.

So while you have demonstrated that issues can occur, they are avoidable, and there is probably little evidence that they are out there in the wild, so to speak. 

I've crammed lots of Girafe's and other's trees onto lots I've made, even overhanging edges, with no problems. It looks like those tiny white squares are the actual tree, with the rest being branches. I'm not positive, but aren't the shadows baked into the model, which would also account for the size.

[nos.17 5,255]

3 hours ago, TheMurderousCricket said:

Digging through the LE and girafe's trees however, I came to a conclusion that the, otherwise beautiful, seasonal prop trees that this user provided are fundamentally flawed as far as the prop occupant size is concerned...

Each of the birches, ashes, poplars (you name it) props that are a part of girafe's bundles have alarmingly small occupant sizes. All of them are 1x1x1 meter.  The vertex data in LE, however, indicates much larger true sizes.

It is not just a matter of numbers. It actually has some very detrimental effects to girafe's trees representation when they are placed in front of other props - the very problem that @rivit has mentioned about props interfering with one another. Girafe's props look as if they were in front of an object while, in truth, they stand obviously behind it. Consider the following example...

Before you go too much further, you might want to check all your variables in play. First thing to do would be to check if they appear the same way in game. A few things could be affecting your conclusion if only made from the LE window preview: the fact that both of the grfe trees are currently selected, the order in which you placed them. The rendering process for the LE preview window is also not going to be the same as in game, which can affect things too.

The occupant size and the actual model size (what I think you mean when you say "vertex size"?) are two different things, and they do not need to be the same. Its a relatively common practice to make the occupant size of a prop or building much smaller than the actual model, and the reasons are many. For one, tt's how you create overhanging buildings/props. I can't speak to girafe's exact intent obviously, but I will safely guess that since nearly all of his models were also released as MMPs, a small occupant size enables the flora to be plopped much closer together than if occupant size = model size, as nothing could ever overlap.

On another note, something definitely looks off with your screenshot and I was unable to replicate. In LE:

And in game: you'll notice there is clipping (which is to be expected because the models are overlapping after all), but on the right they appear in their proper order front to back.

[TheMurderousCricket 5,104]

6 hours ago, nos.17 said:

On another note, something definitely looks off with your screenshot and I was unable to replicate. In LE:

But you actually have replicated the problem! 

In your video it can be clearly seen that the big tree seems to grow out of the seasonal birch while the birch is still in front of it!

6 hours ago, nos.17 said:

Before you go too much further, you might want to check all your variables in play. First thing to do would be to check if they appear the same way in game.

I'll make sure to check it but I am positive that the clipping effect that you mention looked exactly like in LE.

6 hours ago, rivit said:

However, I think it also important to keep in mind that Girafe's trees have seen very widespread use and are a favoured replacement for Maxis trees and so having changes made to them after so many years will be unlikely (a) because of the scope and (b) because of potential side-effects.

Yeaaah... I think this is a good point. Perhaps I'll just edit these myself and be done with the subject. I'll have to check though if it makes any difference at all.

[TheMurderousCricket 5,104]

7 hours ago, nos.17 said:

a small occupant size enables the flora to be plopped much closer together than if occupant size = model size, as nothing could ever overlap.

Props and flora instances are guided by separate .dats in Girafe's case... Aren't they?

In this case one can potentially edit the props while the flora remains intact.

[nos.17 5,255]

19 hours ago, TheMurderousCricket said:

But you actually have replicated the problem! 

In your video it can be clearly seen that the big tree seems to grow out of the seasonal birch while the birch is still in front of it!

On second look you're right about that.

18 hours ago, TheMurderousCricket said:

Props and flora instances are guided by separate .dats in Girafe's case... Aren't they?

In this case one can potentially edit the props while the flora remains intact.

Yes, in general they will be in a file named something like Grfe_props_pack_LE_floraname.dat.

You're welcome to try, but I have a suspicion that might not fix what you want. I had a bit more time tonight so I made some new props with grfe models from scratch without changing from the default occupant size, so occupant size = model size, and I observed the exact same results as the prop with a 1x1x1 size. This kind of confirms what I had been thinking (but unable to articulate well so far) that the occupant size likely should not affect the render order in game and there is more going on.

[TheMurderousCricket 5,104]

6 hours ago, nos.17 said:

You're welcome to try, but I have a suspicion that might not fix what you want. I had a bit more time tonight so I made some new props with grfe models from scratch without changing from the default occupant size, so occupant size = model size, and I observed the exact same results as the prop with a 1x1x1 size. This kind of confirms what I had been thinking (but unable to articulate well so far) that the occupant size likely should not affect the render order in game and there is more going on.

Hello again @nos.17 and thank you for taking part in investigating. 

Yesterday, I did the exact same thing as you did and edited birches and beeches. To the same result may I say...

Some of the trees, especially winter versions, still refuse to render in the correct perspective order so you are right to say that modifying the occupant size doesn't help.

I have to say that Girafe's trees are constructed in a fairly sophisticated manner as sometimes they contain eight vertex groups guiding an object's parts! That's a lot really and probably why the occupant size property does not react as it should.

I just don't understand why their trees as flora are always rendering 100% correct but the props won't...