@wuzelwazel So sorry for not replying back to you. I just had a look for it now (February last year), wow almost a year has gone by. Glad to see your still working on it. I will see if I can find some time soon to have another look as well.

As far as the UDIM work goes I did something similar many years back. I extracted every texture for every triangle and wrote them to a new texture map. And as each triangle texture is extracted to the texture map I use its location for the newly created UVs. I used this for an OpenGL preview as well as rendering. Note that this is not baking at all. Since I am using actual ptex pixel image size directly for each triangle extracted to the texture. So the UV coordinates are based on the actual pixel size in the ptex images. As soon as one texture was full I created another with a new selection set for the triangles and its own material, which could be considered UDIM if I just went out of the 0-1 range, but there was not any need to for my test.

I had planned on doing this again and converting the OBJ files to C4D files in the process, to make them smaller and faster to load. Which is what you are doing with Redshift proxies I believe?

I will reply to your email as well so you have my contact details.

Cheers,
Kent

Not sure if you have seen this or not. But I wrote a Moana importer a year or two back.

https://www.plugins4d.com/moana-island-viewer

I haven't released the ptex loader for it yet. But seeing someone else work on it makes me want to jump back into it as well.

@wuzelwazel you don’t have to build the ptex library at all. You can just directly include the ptex source files.

Edit...

Just checked my ptex plugin, you would also have to set the preprocessor definition PTEX_STATIC and also include zlib. So I guess not so simple :). Nice to hear that vcpkg does this all for you.

Great work on your plugin btw.

Your dlls for OpenSSL will need to be compiled with the same version of visual studio using the same runtime. Then you will need to place these in the res\libs\win64 of your plugin for windows. OSX has a similar folder. Note that you will have to compile it for yourself on OSX as well now since I believe it has been removed from the default installation for OSX in Catalina. Alternatively you could look at using libcurl (depending on what you are doing), since for windows you can compile a static lib that uses WinSSL, and libcurl is still included with OSX.

It could be. I never got around to investigating it any further. But if/when I do I will have a look at that flag for sure. Since in my tests there was definitely something going on with the polygon indices. Thanks for investigating this further and also for reporting your findings. Really helpful.

@zipit said in Generator crashes and guidance:

OBJECT_DONTFREECACHE

Yes that is the flag. If you enable that flag then you own the objects. And you pass the pointer as the result of the GetVirtualObjects call. But you MUST ensure correct deletion of the objects when the generator is deleted. And you must handle all read/write/copyto calls correctly for your generator.

@eldiren

You should not store the pointers to the BaseObjects in a std::vector. Instead use BaseLinks. Store them in a BaseArray, you may have to put them i a struct and add the struct to the BaseArray.

The reason for using a BaseLink is because C4D can delete the BaseObjects and change them. The BaseLinks are correctly updated to point to the new object pointers.

So your std::vector is most likely pointing to random memory which is causing your random crashes.

This is because C4D is owning the objects if you are just passing them back in the GetVirtualObjects method.

If you want to own them and keep a pointer to them yourself then there is a flag for generators that you can pass in when you register the generator object. In this case storing the pointer like you are doing is fine as long as you make sure you handle all read, write and copyto methods to correctly duplicate all internal objects that the generator, ie you, own.

I am on my phone at the moment so can’t give an example, I am sure someone else will post something up if you need it. Including the flag. Otherwise I will find it tomorrow for you and post it up.

Kent

Looks great Loïc.

It would be great if you could also add in the Timeline Markers to indicate where each animation starts and finishes.

Here are a couple of posts that should help.

https://gist.github.com/gr4ph0s/0badf708657aaa117be0f84dd176e2b8

https://developers.maxon.net/docs/Cinema4DPythonSDK/html/modules/c4d.documents/index.html?highlight=addmarker#c4d.documents.AddMarker

Cheers.
Kent

I am not exactly sure how it works in Python but I will give you a run down of how Global Variables work in C++.

If you set a global variable in C++, and you are using it in a Generator Object, then that variable will be exactly the same in every object in every document that you have open. So if you change the value of it on any object (again in any document you have opened) it will be changed across everything. That is the definition of a global variable. It is global, it is the same everywhere.

Now it may not work exactly like this in python depending on how it is setup in C4D. But in general it is a bad idea to use this for ay variable in something like a generator object.

So even though it might be working for now in a basic test scene, it will come back to bite you once you use it for anything more complex, such as two or more objects.

It all comes down to what it is that you are trying to achieve and what this data is that you are using in a global variable.

In C++ you could use a SceneHook to hold scene wide data. But I don't think that is in Python yet, so the best option to use scene wide data is to use a PluginID as your way to access that data in the preferences for your scene.

For storing a matrix value to compare why don't you just use a local variable in the generator object itself?

Also I would avoid using the word "Save" when you discuss this data, since "saving" and "persistent" mean writing data to disk. And that is not what you are doing. But if you did want to save the value then just make the matrix a description in the resource files for your object generator and access it using the BaseContainer. Then it will be saved automatically.

Cheers,
Kent