Why do Floofs have a decoration cost of 5?

[DarkLight748]

Why do static decorations, like Floofs, and dynamic decorations, like Noggle, have the same cost? Surly static decorations should be less, would really like to see the decoration cost of Floofs decreased so I can have more in my orbiter.

[Legion-Shields]

no

[peterc3]

35 minutes ago, DarkLight748 said:

Surly static decorations should be less

Based on what?

[YeAhx_]

33 minutes ago, DarkLight748 said:

Why do static decorations, like Floofs, and dynamic decorations, like Noggle, have the same cost? Surly static decorations should be less, would really like to see the decoration cost of Floofs decreased so I can have more in my orbiter.

Probably for the sake of simplicity, imagine changing decoration cost of anything added new depending on their size, type etc.

Maybe noggles should cost more than 5 capacity cost (but then DE wants us to buy and use as many as we can)

 

Spoiler

Kudos to the guy up there with his deep "no" discussion

 

[Legion-Shields]

3 minutes ago, YeAhx_ said:

 

  Hide contents

Kudos to the guy up there with his deep "no" discussion

 

Thanks ye matey.

[(PSN)N7_Dredgen]

13 minutes ago, peterc3 said:

Based on what?

well I mean in terms of 3D modelling dynamic/animated meshes are almost always more memory intensive than static ones, the only thing that would change that is poly count (and you can pretty much tell just by looking that noggles are still higher in poly count too.)   It stands to reason that decoration limits are set based on memory requirements per object (in fact we know from previous discussions and devstreams that this was originally the case), so it's logical to assume something like Noggles would in fact take more "size" than something like a Floof.

Edited June 22, 2019 by (PS4)Zuzu_with_a_Z

[LSG501]

To be honest you could realistically break it down in a much more simple manner:

• noggles - in most cases are plat - DE profits
• floofs - not available for plat - DE makes no profit

 

[DarkLight748]

44 minutes ago, Legion-Shields said:

no

Thanks for contributing to the discussion.

36 minutes ago, peterc3 said:

Based on what?

Based on the cost of rendering, as above poster said a dynamic object takes more resources to render\animate than a static one. Why should a full Ayatan cost the same as an empty one? That is what the decoration cost is there for, to stop the game from getting overloaded.

[Legion-Shields]

1 minute ago, DarkLight748 said:

Thanks for contributing to the discussion.

 

You're welcome.

[Oreades]

9 minutes ago, DarkLight748 said:

Based on the cost of rendering, as above poster said a dynamic object takes more resources to render\animate than a static one. Why should a full Ayatan cost the same as an empty one? That is what the decoration cost is there for, to stop the game from getting overloaded.

Well my guess on the Ayatan angle is that it's because both the full and empty Ayatan use the same models so it's loading in the same number and groupings of polygons with the same codebase to move around regardless of the actual movement of the ayatan itself. At least I'm guessing the bulk of the capacity comes from those aspects and not so much the movement aspect. 

[Rin-senpai]

15 minutes ago, Legion-Shields said:

You're welcome.

Simply man...

[peterc3]

25 minutes ago, (XB1)Cubic Clem said:

Give me break dude.. you're starting an argument just for the sake of it..

Well, to me it is not obvious that a noggle and a floof shouldn't have the same resource cost. I was wondering how they came to this conclusion.

[YeAhx_]

1 hour ago, LSG501 said:

To be honest you could realistically break it down in a much more simple manner:

• noggles - in most cases are plat - DE profits
• floofs - not available for plat - DE makes no profit

 

This seems to be the only logical reason behind it rn unless DE explains if its intentional

[Ghogiel]

15 hours ago, (PS4)Zuzu_with_a_Z said:

well I mean in terms of 3D modelling dynamic/animated meshes are almost always more memory intensive than static ones, the only thing that would change that is poly count (and you can pretty much tell just by looking that noggles are still higher in poly count too.)   It stands to reason that decoration limits are set based on memory requirements per object (in fact we know from previous discussions and devstreams that this was originally the case), so it's logical to assume something like Noggles would in fact take more "size" than something like a Floof.

In the worst case scenarios of placing decorations, these cases of non blendweighted animated meshes aren't going to be much worse then say floofs. The draw call over head is almost certainly going to be the bottleneck and not vert count or transform cost if every item placed is unique. The scene will hit being fill bound and not transform bound, therefore they have similar rendering costs in practice. Obviously different if batching can be involved because you are only using a few of the same items, then maybe you can start find the transform cost for a particular scene before vram and fill rate bottleneck.

Basically texture and materials are in most systems and scenes going to be what kills your performance and what the devs will look at when determining these limits. So while it's correct that there is more going on with a noggle, it's probably not the thing that's going to bottleneck first in the worst cases.

Edited June 23, 2019 by Ghogiel

[Mr.SpookSpook]

Complaining about something costing 5? Really? When you should be complaining about articulas costing 100, which really is a problem?

[Qmiras]

19 hours ago, DarkLight748 said:

Why do static decorations, like Floofs, and dynamic decorations, like Noggle, have the same cost? Surly static decorations should be less, would really like to see the decoration cost of Floofs decreased so I can have more in my orbiter.

I have another good question! Why do thumpers floofs use cetus wisps?

So you need a basically magic living thing to create a innanimated object.... So we are basically creating a Chucky doll...