Storing Images in Scene Files?

On 08/01/2013 at 23:41, xxxxxxxx wrote:

Yeah.  There is more that you have to do and where it is done is important.  Here is a zip download that contains the source and res that works:

http://www.kuroyumes-developmentzone.com/wp-content/uploads/2013/01/Z_PluginTestProject.zip

Note that you have to always have Alloc()'d the BaseBitmap, even for hf->ReadImage().

Note also that I define C4D_RXX as preprocessor directives to rectify SDK version differences.  You should be able to get away with defining only C4D_R12 and C4D_R13 (depending on the version you are building for).

On 09/01/2013 at 02:39, xxxxxxxx wrote:

The reason you are getting a crash on Read() is that you haven't allocated a bitmap for the data to be loaded into. You have a pointer but it's just a pointer to nothing - it probably has a null value - so you get an access violation the moment it's used.

If you AutoAlloc a BaseBitmap as a class-level variable, you can use that and it shouldn't crash on read.

On 09/01/2013 at 08:29, xxxxxxxx wrote:

God bless you Robert.
You have no idea how many days of hair pulling and dead ends I've gone through trying to figure this out.

It turns out that I don't need to use the CopyTo() function at all. But it's nice to see an example of how to use it if I do need it some day. The example given in the docs is of no help at all to someone who hasn't used it before. Your code example is much more clear.
All I needed to do to make it work was put BaseBitmap::Alloc(); in the Init() function.
Now it's working and I'm on my way to the next step.

@Steve,
Thank you for your advice too.

-ScottA

On 09/01/2013 at 23:07, xxxxxxxx wrote:

Originally posted by xxxxxxxx

It turns out that I don't need to use the CopyTo() function at all. But it's nice to see an example of how to use it if I do need it some day.

If the user copies and pastes the tag (in the same document or a new one), they might get a BaseBitmap allocated through Init() but CopyTo() ensures that they get a copy that has been initialized and contains the same image (as was presented in my code).  In other words, never assume that the user will never do something that you don't think that they will do - they expect a lot and usually to our (programmer's) demise ;). It may be that they will not expect the image copied and will use a new image - but it is most likely that the user expects that the copied plugin retains all of the information contained in the original.

On 10/01/2013 at 08:35, xxxxxxxx wrote:

Oh. OK.
Thanks for explaining that.

-ScottA

On 24/01/2013 at 12:07, xxxxxxxx wrote:

I've got everything working like I want now with one bitmap image stored in the tag.
But I'm having a very hard time doing it with multiple images.

ASFAIK. The overridden Read() & Write() methods can't read images from an array. Since all my attempts to do so have failed misearbly.
So I was wondering if maybe I could use the level option in place of an array?
Maybe I could write each bitmap to it's own level. Then use those levels as index numbers to assign them to a specific bitmap button?

The problem is I can't even test this out. Because the SDK doesn't say how to Write a level.
It only shows how to read a level.
Can anyone tell me how to write a new hyperfile level in the overriden Write() method?

-ScottA

On 24/01/2013 at 12:23, xxxxxxxx wrote:

Hi Scott,

Try something like this:

Bool MyObjectData::Write(HyperFile* hf) {
    Bool result = ObjectData::Write(hf);
    if (!result) return result;
  
    /* Assuming `bitmaps` is a GeDynamicArray<BaseBitmap>* object. */
    /* Write the number of bitmaps in the array to the file, so we */
    /* later know how many bitmaps to read. */
    LONG count = bitmaps->GetCount(); 
    if (!hf->WriteLong(count)) return FALSE;
  
    /* Iterate over all bitmaps and write them to the HyperFile. */
    for (LONG i=0; i < count; i++) {
        BaseBitmap* bmp = (*bitmaps)[i];
        if (!hf->WriteImage(bmp, FILTER_PNG, NULL, SAVEBITS_ALPHA)) return FALSE;
    }
  
    return TRUE;
}

Reading should be similiarly simple.

Best,
Niklas

Note: I did not compile this code yet, serves just a demonstrational purpse.

On 24/01/2013 at 15:03, xxxxxxxx wrote:

I'm not able to make that work yet...But still trying.

I think I'm trying to do something that just isn't supported.
I don't think the built in hyperfile is designed to serve up multiple images like this.

-ScottA

On 24/01/2013 at 15:09, xxxxxxxx wrote:

Can you upload your current code?

On 24/01/2013 at 16:06, xxxxxxxx wrote:

Sure:https://sites.google.com/site/scottayersmedia/Dialog_StorageTag.zip

This plugin works exactly how I want. But only with one button and one image per StorageTag.
Let me explain a little bit about what it does:

-When the plugin's dialog is open. If the currently selected object also has my "StorageTag" on it. And the bitmap button is blank. Pressing the bitmap button will render the current scene and place that image on the button.

-If there is an image already on the button. It will not re-render a new image( this is intentional by design)

-If the object with a Storage tag has children. The children are also rendered
 If the object has no children. Only the object itself is rendered

-Selecting different objects in the OM with StorageTags on them makes the bitmap buttons automatically change respective to the selected object.

-If the scene is saved. And then opened. The old image will still be on the dialog button

All of this is working nicely just how I want. But It's limited to one button. And one image per StorageTag.
My final version will have multiple dynamically created bitmap buttons on it. So I need a way to store and retrieve multiple images from the hyperfile. And some kind of way to index them so they can be assigned to specific dialog bitmap buttons as they are added or deleted.

-ScottA

On 24/01/2013 at 20:01, xxxxxxxx wrote:

It is assuredly possible to store as many images as you would like to the hyperfile.

Two important points you should consider:

1. You should create a LONG description in your tag to store the number of bitmaps currently in the array so that upon reading, you know the number that were saved and need to be read (otherwise, how would your code know? - this will surely end poorly if that number is not known).

2. For retaining button-image assignments, you will need to store that information somewhere.  You could create a separate array that mirrors the bitmap array to store, say, the button ID.  Or you could create a simple class that stores a BaseBitmap* and the button ID that you create as an array of instances.  You would then go through the simple class array to store the bitmap (WriteImage()) and ID association (WriteLong()).

Realize that the reading-writing process is in tandem.  That is, the order that you write data is the EXACT order that you must read it.  The C4D file format is not random access - it is linear data (possibly chunked, but not important).  The good thing though, is that static descriptions are always read before Read() is called so that they are available in Read() by default.

Finally, you need some way to do this.  Yes, you will need to figure out what information is required to retain the bitmaps and their correct button associations and write-read-copyto that information for it to be retained in file.  Also, upon reading, you need to allocate any dynamic structures (arrays, class arrays) that hold this information and data just like when the tag has it allocated otherwise.  If you have an array of BaseBitmap* in which you store the images, you will need to allocate an array of BaseBitmap* in Read() not only to read in the images but to store them just like when images are added, say, by the user.  Read() needs to reestablish all of the member data as it was while live in the tag when in use (as long as the member isn't just for some intermediate processing).

On 24/01/2013 at 22:12, xxxxxxxx wrote:

@Scott: You don't have to explain me, I did already write a you a full
plugin doin' what you wanted it to do earlier. I'll look into it at a later
minute.

@Robert: Why does he need to create a LONG description? This would
let the user modify it. And even when hiding it, the value could be set
via a script or similar. Preventing that with overriding Message() would
just be an in-ideal design. The number of bitmaps stored in the tag
should be known always during run-time. This value can then be written
to the HyperFile (just as I did above).

I do not understand why he would need to write the ID of the button in
the dialog to the file, but that might depend on the requirements.

-Nik

On 25/01/2013 at 07:51, xxxxxxxx wrote:

Originally posted by xxxxxxxx

@Scott: You don't have to explain me, I did already write a you a full
plugin doin' what you wanted it to do earlier. I'll look into it at a later
minute.

It's kind of important that you read that explanation. And look at the plugin I posted. Because the plugin you made earlier worked completely differently. It did just about everything except what I wanted.
You had images saved in the plugin's folder swapping each other to be displayed on a button.
What I'm doing is showing images(or no image at all) on buttons. Depending on the saved images in the object's StorageTag.
The plugin you posted was still very helpful for me though. I learned something new about creating custom messages with it that I didn't know before.

I'd still like to know how to write new levels into a hyperfile.
Why does the SDK show how to read them. But not how to write them?

-ScottA

On 25/01/2013 at 08:39, xxxxxxxx wrote:

Originally posted by xxxxxxxx

I'd still like to know how to write new levels into a hyperfile.Why does the SDK show how to read them. But not how to write them?-ScottA

You don't write a new level. It's a different concept that takes a moment to get your head round.

Suppose you write a plugin which saves some stuff to the hyperfile using Write(). You read that back in again with Read(). Now suppose you write a new version of your plugin which during Write() saves some more data in addition to the original stuff.

There's a problem now because two versions of your plugin are circulating. The new version can read files created by the old version and the new version, but the old version doesn't know anything about your new version. So when it comes to read a file created by the new version, it will read data which is the 'extra' data written out by the new version, thinking that this is the data it wants. This could have various effects depending on what the data is - anything from working incorrectly up to a crash.

Levels are the answer to this. If the plugin is level 0, it will ignore any level 1 data it finds. If it's level 1, it will read the level 0 and the level 1 data. Likewise a level 1 plugin will ignore data created by a level 2 plugin, and so on.

You don't have to write the level to the hyperfile, Cinema does it for you. It knows the plugin level because you told it when you registered the plugin - look at the disklevel parameter in RegisterObjectPlugin() for example, that's what it's for. Mostly that parameter is ignored, but it's vital if you are using Write/Read and you release a different version of the plugin which stores more data.

On 25/01/2013 at 09:59, xxxxxxxx wrote:

Ah shoot. Another dead end that won't help me at all.
Thanks for the clarification Steve.

I hope the Maxon developers are taking note of this thread. There are situations where storing images to HD files just won't work.
There are times that we need a way to store images locally in tags or objects so a dialog can use them interactively.
Nitroman for example uses a camera and view panels in his NitroPose plugin to do what I'm trying to do with a storage tag.
It would be much better and cleaner if we could store our GUI images locally in a hidden tag, object, or UserData.

-ScottA

On 25/01/2013 at 10:47, xxxxxxxx wrote:

Originally posted by xxxxxxxx

I hope the Maxon developers are taking note of this thread. There are situations where storing images to HD files just won't work.
There are times that we need a way to store images locally in tags or objects so a dialog can use them interactively.

How can you say it's not possible to save images within tags or objects plugins?

I've just seen your code and if you remove the 2 'if level' conditions in the Read(), it should work as expected.

On 25/01/2013 at 12:19, xxxxxxxx wrote:

Hi Yannick,

Good to know you're watching this.
Yes we can save images to the hyperfile. But it's a FIFO stack with no way if getting or changing their indexes.
In order to be able to assign specific saved hf images to specific GUI items like buttons. We need a way to index them to tell them apart. And to use those indexes to assign them to gui items.

Robert is talking about writing a custom indexing system to solve this problem. Which is rather complex for the average coder like me. I don't think I can pull it off.
It would be nice to see something in future versions that would possibly make it easier for the average user trying to save things locally. Like maybe some sort of storage tag class with indexing options.

-ScottA

On 25/01/2013 at 15:49, xxxxxxxx wrote:

Scott,

I think part of the problem I'm having is visualising exactly what it is you're trying to do. I *think* you want the user to be able to pick which images get assigned to a set of BitmapButtons, so that your hyperfile needs to be able to store a series of images. Presumably that could be a fixed number (e.g. there are always going to be n bitmaps) or it's variable so the user can add more bitmaps. It doesn't matter either way.

Now, if that's that case, it's very easy to do. What I would do is this:
* store the pointers to all the bitmaps I'm going to use in an array of pointers to BaseBitmap(s)
* I can now access each bitmap by means of its index in the array
* each BitmapButton has a value which is the index into the array of the bitmap it's going to show - it's easiest to store this as a hidden field in the description because then I don't have to worry about saving or copying this value
* I use that hidden value as an index into the bitmap pointer array to get the pointer to the bitmap I want and assign that bitmap to the button

When I Write() the hyperfile, I would do this:
* first, write a LONG which is the number of bitmaps I have in total - say it's 6, for example
* then write 6 bitmaps using the 6 pointers in my array

When I Read() the hyperfile, I do this:
* read the LONG which tells me the number of bitmaps I have to read
* allocate the 6 BaseBitmaps so I have somewhere to store the data
* store the pointers to those BaseBitmaps into my array of pointers
* read the 6 bitmaps from the hyperfile
* the hidden value in the button description then marries up with the correct bitmap - I'd need to check that the value was valid in case something had gone wrong, but other than that I can forget about it; when MSG_DESCRIPTION_GETBITMAP is sent for a particular button, all I'd need to do is retrieve the hidden value in its description and use that as an index into the array of pointers to bitmaps

That's basically it. I suppose I'd have to provide some method in the interface for the user to be able to select which bitmap he wanted, but that's simple. The only other thing I would have to do is implement the CopyTo() function to copy the bitmaps, array of pointers, and the value holding the total number of bitmaps I have into the cloned tag.

I just don't see the problem. It doesn't need lots of extra SDK functions to do this.

On 25/01/2013 at 17:48, xxxxxxxx wrote:

What I'm doing is creating something similar to the old PoseLibrary system that used to be in older versions of C4D.
The bitmap buttons are created & deleted dynamically. So there isn't a set number of them.

When my "Create Pose" button is clicked in the GeDialog. A whole bunch of things happen:
- A custom StorageTag is added to the currently active object (if it doesn't already have one)
- The current Position & Rotation values of the active object are saved as UserData to the tag
- A bitmap button is dynamically spawned in the dialog that allows the user to set the object to these UserData values(poses)
- A delete checkbox option for this specific button is also dynamically spawned so it can be deleted
- The active object is rendered. And the image is placed on the bitmap button(This part is the problem) so the image is there on the buttons. Even after the scene has been saved, closed , and re-opend.

The frustrating thing is I wrote this plugin in about two days after learning how to create and delete UserData with C++.
It's working fine except for the images. And it even has a tree gui in it for selecting the objects so the user never has to touch the OM. Allowing the user to do everything from inside the GeDialog.

But the button images...holy mother of god...What fresh hell is this!?  
I never would have believed  that it would be 10x harder to figure out a way to store the button images locally in my tags. Than writing my entire plugin.

-ScottA

On 26/01/2013 at 02:33, xxxxxxxx wrote:

If I read this correctly, an object can have multiple storage tags each holding some PSR data and one bitmap, is that correct? Then what you need to do is allow the dialog to communicate with the tag.

Once you have your rendered bitmap, I take it you can assign that to the button, yes? So now you need to point the tag to the rendered bitmap. On Write(), each tag saves its own data and bitmap. On Read(), each tag loads its own data and bitmap. When you recreate the button layout in the dialog, you iterate through all the storage tags, get the pointer to the bitmap, create a button for each one and stick the bitmap on the button.

Or have I got this completely wrong?