Open Arkie001 opened 2 years ago
the extra components are there to edit the size of the quad to fit the size of the image getting rid of these components would end up with all your photos being squares
Which components cause issues? Most are entirely harmless and cause no performance issues although I could see a problem with Grabbable maybe?
What's the usecase here, why do you need this?
More components = larger datamodel. World syncing (on join and save) becomes a real slog on larger worlds. Having a massive amount of images that have 3 components would be at least an improvement over ones that had 9 or so.
In my opinion that's a problem for Neos to solve.
Those components are useful so if we can get away with keeping them we should. If we started removing seemingly optional components we'd end up with a lot of strange behaviour in many areas. Some of the components that would be removed have very useful features that aren't always immediately obvious.
Clarification for use case is I am importing books and loading them into a tablet of sorts for edu use and anything else people want to use it for. Primarily it is the grabbable and collider component.
As for data size, removing the components in the list below saves about 3MB per 1000 pages Grabbable Texture Exportable ItemTextureThumbnailSource SnapPlane ReferenceProxy AssetProxy BoxCollider Float2toFloat3SwizzleDriver
Regarding the weird behavior from removing components, I agree that in the default case for images being imported they should have all the current components. My thoughts are more of an advanced import settings menu much like we get when importing avatars.
Lastly, for the components driving the size. In the end the size is driven by the QuadMesh component, which would still be kept due to it being the mesh that the material/texture is applied to.
@Arkie001 - Okay- so a good way to summarize is that you are just looking for a mechanism to import a bunch of texture assets directly without setting up a corresponding object for each, yeah?
For the most part yes, but I would still want each to have the quadmesh, renderer, and material component so each can be seen but not interacted with when enabled.
I think it'd be better to rethink the way you make the collection. For example, store just the asset URI and multiplex it onto the same screen instead of storing and reshuffling a thousand of photos. It should be possible to make a constructor using an AssetFrame and a bunch of LogiX.
On the topic of combining the pages into one texture - Neos has support for Texture Atlases. That's how sprite animations are done, but you can switch "pages" manually too. You just need to set up how many rows/columns are in the texture.
Is your tweak request related to a problem? Please describe.
Tweak is not related to a problem
Describe what would you like tweaked
I would like an option added to the image importing/bulk image importing so that imported images would only contain the components: 1) QuadMesh 2) MeshRenderer 3) StaticTexture2D 4) UnlitMaterial
Describe alternatives you've considered
I have considered going in and individually removing the components, but that is not realistic when image count is in the thousands. My other thought was combining all the images into a single massive image and move a camera around as needed, but decided that the complications with looking at more than one image at a time may become cumbersome.
Additional context
No response