LoadModel, Sound, Mesh, Texture from memory

[wh1sp3r]

It will be good to load model from array. I can use C function to load file into array and call command LoadObjectFromArray( char* array, int parameters) ... etc

 

why is it good ? because we can have own loading mechanism, multithreaded loading from memory is fast enough in realtime (i think)

[Josh]

What does this have to do with multithreading?

[Masterxilo]

I guess he thinks that most of the slowdown from loading meshes and other files comes from reading the data from the HDD (which might be true).

So one could load the files into memory in a separate thread and then tell the engine to load the stuff from there.

[wh1sp3r]

yes, exactly Masterxilo

[Rekindled Phoenix]

I second this request!

[Pixel Perfect]

I also think it would be great to be able to load these things from memory

[Rick]

I agree with this, and honestly it should be as easy as copying the memory from one thread to another.

 

This must be possible. If someone knew how to sniff around memory they should be able to figure out the structures of these entities and be able to get this going. I would assume one you knew the memory structures of say a Mesh and all the related memory structures needed around it, you would be able to copy that memory from one thread to another.

[Mumbles]

I wanted to suggest this a while ago (Dec '09 sort of time) but I also spotted some complications. When a model is loaded, say "something.gmf" the engine searches for:

something.gmf

something.phy

something.mat

somethingLODx.gmf

 

How would this be done with memory? You would have to provide a memory address for at least the first three of those.

How would it handle LOD meshes? The only realistic way I could think of was the ability to add them with separate function calls later on

Example:

TModel Something = LoadModel("Something.gmf");
AddModelLOD(Something,2,"SomethingLOD2.gmf");

 

Without something like that, you would have to make the engine aware of how many pointers you want to pass.

 

Then there's mat file issue. How would you specify the texture being in memory? You simply cannot know where your texture is going to be allocated.

 

I mean I would be in favour of packing everything into a single (encrypted) binary file that you can decrypt once it's in memory. The file would say how many LOD meshes there were, how many textures there were, and would list the size of each mesh / physics file, so you could know how many bytes to skip when loading of portion of the overall model.

 

But simply saying you want to load from memory, I don't think is a very good idea unless you could describe ..how.. you want to load from memory.

 

I was thinking about this again recently, because I was thinking about writing a short tutorial about quick, simple encryption. But I soon realised that there is no practical use for it in Leadwerks, because you have to load the decrypted files from the hard disk. Anyone being concerned enough to want to encrypt their assets in the first place will know that the the second their decrypted files hit the hard disk, they're vulnerable.

 

 

Edit: I should add the the issues I listed mostly only apply to LoadModel. Loading an individual texture / sound from memory should be relatively straight forward.

[Rick]

Ideally, it would be nice if we could get a pointer for any loaded entity. Some kind of function like, GetEntityPointer() so we have the memory address to start with. Then if we could get a detailed description of the memory structure for each entity. If we had that we should be able to do some cool things. You could get the entity for texture and/or material on a loaded model. Then from that you could call this GetEntityPointer() method to get the memory location of it. Then use that types memory layout to copy it.

 

There has to be a way to get this information, with some kind of memory sniffer and some trial and error.

[Sean]

i would LOVE to be able to load a texture from memory. I want to create a 3d slideshow using photos from a folder. Currently i can't load .jpg, .bmp etc. as a texture. ( or at least not that i am aware of ) The .dds converter tool is just too slow.

[Rick]

As I'm thinking about this, and messing around with memory sniffers, I think one would have to someone add the TEntity value that gets normally returned, to some kind of list on the main thread. I assume the main thread has a list of these that point to the internal storage so it can act on the data. Not sure how one could do that.

[TylerH]

The handles exposed in the DLL are actually memory pointers, integers.

[L B]

This is basically solved with the UNIQUE flag in LE3.