castledb-unity-importer
castledb-unity-importer copied to clipboard
kkukshtel
CastleDB "Image" type Support
CastleDB supports images in rows. It's an open question right now if this should support that functionality now as well as how it should be supported. Per the CastleDB documentation: "the string of the MD5 of the image content bytes, stored in the separate .img JSON data".
I think that a possible (crazy) use would be essentially generating runtime textures from the .img data and then accessing that in code. This would likely be pretty hard and also require a change to the config file as each user would want to use this differently.
One approach (for a 2D tilemap based game) I am currently using is to have all my images already sliced in a Sprites folder that at runtime gets loaded into memory and assigned attributes based on the JSON data tied to its MD5. We could implement this as a demo for others to use I suppose. An added benefit of my approach is the use of a texture packer class that will do the heavy lifting of building tilemaps so the user only needs to supply a bucket of images and the game provides them a way to access each by name.
I think that’s definitely a possibility but it should be a bit more generic. Ideally it should just allow you to access a texture in memory at runtime. I don’t know what the overhead would be though at runtime. I think this is also similar to how the Futile framework works.
A possibility would be to allow images through always requiring a dedicated “Images” sheet where you have an image reference and then also import settings for each image in a row. On Wed, Aug 15, 2018 at 1:09 PM Fuad Mefleh [email protected] wrote:
One approach (for a 2D tilemap based game) I am currently using is to have all my images already sliced in a Sprites folder that at runtime gets loaded into memory and assigned attributes based on the JSON data tied to its MD5. We could implement this as a demo for others to use I suppose. An added benefit of my approach is the use of a texture packer class that will do the heavy lifting of building tilemaps so the user only needs to supply a bucket of images and the game provides them a way to access each by name.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kkukshtel/castledb-unity-importer/issues/6#issuecomment-413266391, or mute the thread https://github.com/notifications/unsubscribe-auth/AHW5zwxIE2EjSDzO0TM4Yor2HNucAYUCks5uRFXIgaJpZM4V9X6E .
So you would prefer an approach where the sprite sheet is kept in the active memory object of the DB?
My approach is pretty generic I suppose...
// Load all images from sprite folder into packed texture object (this has functions for directly accessing a single sprite either by name or by filter)
// DB has a field that holds the packed texture for the entire database that a DB sheet object can access when building its respective objects
This gives you single packed reference for sprites in the entire DB only accessible by the DB sheet objects. I also removed the enum generation of all objects and instead have it load at runtime into a dictionary of id -> SheetObject. During the loading of objects into their dictionaries, I lookup the loaded sprite and attach it.
An even more generic approach would be to have an image loader function in the DB that at runtime can load the individual sprite and provide it, independent of a secondary image list that loads them beforehand.
Just realized that a ".img" is created for the DB, so I will use that to load from :). I need to learn to fully read the manual sometimes.
I think a version of what you are suggesting here is definitely an ideal outcome of this, but I wonder if people would want to use it for different reasons? Like if your sheet stored references to lots of 4K textures, storing all those in one sheet wouldn't be a good idea. This kind of brings me back to having an "Import Settings" sheet, but that feels a little too aggressive. What's a simple way to support images? Can we start with serving them as single objects?
In the PR I sent regarding this we have each image loaded as a separate texture object. This is probably okay for most uses but we could take it a step further and have the config object decide whether the database builds the code as separate textures or as sprites loaded into N texture atlases.
Just left you a comment on your PR! I think you cracked the image loading itself for sure but I want us to start small and just support it per sheet for now. If we have to do some crazy import setting stuff in the future I think this could ideally pave the way for that when it comes up out of necessity. Also maybe that whole route could be handled with CastleDB's custom types support? Like there is just a "Unity Image" field that takes a texture along with some settings, but I don't fully understand how these custom type stuff works!