@kbar said in Ptex Shader Progress:

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?

Yes, the Redshift Proxies work as a sort of reference so the main c4d file would be quite small. In addition the display of each proxy can be simplified to either reduce or eliminate the viewport being bogged down with drawing faces. Of course, when everything is just a bounding box the scene doesn't look like much before rendering!

The other benefit of the proxy is specific to Redshift in that the mesh will not need to be processed before the BVH is constructed and rendering can begin.

@kbar I have seen your importer! I even tried to contact you through your website's form to share the python script that I'd been working on to convert the dataset in the hopes it would be helpful. I'd solved correction of the transform matrices and had placement of instances, archives and curves working really well.

My goal was a bit different though, I wanted to convert the Ptex textures into UDIMs, build the materials, build Redshift proxies from the various assets and then instance them into the scene. There were only 2 things that held me back at the time:

1. OpenImageIO couldn't read many of the Ptex files properly.

2. The enormous size of some of the JSON files made accessing them with the built-in Python json module incredibly difficult as it would attempt to load the entire file into memory.

What I'm trying to do now is solve #1 by circumventing OIIO all together. Although after posting this shader I realized that it would be much more efficient to create a command plugin I could call from Python that would:

-Read the associated Ptex files
-Setup the UDIM UVs on the objects
-Write the Ptex sub-images directly into a bitmap following the UDIM layout

That wouldn't be helpful in a general Ptex workflow, but would get me what I need much more efficiently (no need to bake textures in a separate pass).

As for #2 I did find the ijson module, which would allow me to iterate through the larger json files without loading them entirely into memory.

I've managed to stumble my way through to a working (debug) prototype of a Ptex Shader. It "works" but I've been developing it with a very specific purpose in mind: converting the Moana dataset Ptex files to UDIMs. As a result, and due in large part to my inexperience with C++ and the SDK, this prototype is missing pretty much all of the features it would require to be a production ready shader I'm not doing proper error checking and it's quite possible I've written a memory leak or two in here

Most telling: the plug-in is crashing when I switch the build to release. Debug is working, but I am unfortunately clueless when it comes to debugging

This Ptex shader doesn't work under several conditions that would need to be addressed if I were working on this for other people to use in production:

• Doesn't work if the mesh has been subdivided (no correction for the change to polygon indices and coordinates)
• Similarly doesn't work as an input for sub-polygon displacement
• Only reads .ptex files whose filenames match objects that the shader is being evaluated on
• Only works on Windows
• Only works with a Debug build
• Not designed as a general purpose shader, specifically built to work with the Moana dataset

With all of those caveats out of the way, I've uploaded the source to Google Drive in the hopes that folks will point out the idiotic things I've done so that I can improve and also so that someone more capable might pick this up and carry it through to a real shader

P.S. For anyone working on Windows that doesn't yet know: I highly recommend picking up vcpkg. If I'd had to build Ptex from scratch I don't think I'd even have gotten this far.

@PluginStudent

Thanks for the suggestions. I will definitely use your super obvious (in hindsight) recommendation to check the emptiness of the original String!

Could you encapsulate briefly why I might or might not want to take ownership of the CString array? I have a gut feeling that using the GetCString() method you suggested is safer but I have no knowledge to back that up Error handling is definitely something I need to better familiarize myself with.

Lastly, when would I need to use the maxon namespace? I sort of assumed that these two would be equivalent:

const String fileString = fn.GetString();
const maxon::String fileString = fn.GetString(); // significance of namespace here?

Is it a situation where if String also exists in another namespace then not providing the explicit namespace would result in ambiguity for the compiler?

@m_magalhaes

Thanks Manuel!

I realized that there are a couple of specific pieces of the puzzle that I'm not sure how to handle.

I need to pass file paths between Cinema 4D and Ptex. I think the most straightforward way to do this is to use a CString to go between them, but I ran across several potential ways of approaching this. What is the preferred method? I'm currently trying this in InitRender():

String filename = data->GetFilename(PTEX_FILE_PATH).GetString();
Char* filestring = filename.GetCStringCopy();    // I noticed on a page in the docs that Char* was used as opposed to char* what is the reason for that?

if (filestring[0] != '\0') // is this the best way to check for an empty CString?
{
    ptexTexture->open(filestring, err, true);
    // ...set up additional data based on loaded texture
}

DeleteMem(filestring); // The SDK says this is necessary when using the GetCStringCopy() method

Is this correct?

Additionally, I've realized that in my Output() function I will need access to the object's name in order to determine which Ptex file to sample from. Would this be the way to get that information in the Output() function?

String name;
BaseObject* obj = cd->vd->op->link;

if (obj != nullptr)    // If I'm checking for nullptr could I just use if(obj) as in Python?
    name = obj->GetName();

Thanks as always for your awesome support!

Hello there,

I've taken my first leap into the C++ SDK and experienced some early triumphs and defeats. I'm working slowly on a shader starting from the Xbitmapdistortion SDK example. I have the SDK documentation open in about 20 tabs but still feel unsure about how I'm approaching what I'd like to accomplish.

I'm hoping to write a bare bones Ptex shader. I don't need to deal with most of the issues that surround Ptex as my only goal is to get a shader that I can bake into UDIMs I figured I'd start the effort by generating per-polygon UV coordinates. It took me a while but I came up with a working solution which exists mostly in the Output method of my young shader:

Vector PtexData::Output(BaseShader* chn, ChannelData* cd)
{
	if (cd->vd == nullptr) // It took me a while to realize I needed this here :)
		return Vector(0.0);

	RayPolyWeight weight;
	RayHitID hit = cd->vd->lhit;
	Int32 faceid = hit.GetPolygon();
	/* I'm not currently using the faceid, but I will need it to index into the sub-images
	of the Ptex file; is this a bad idea? Is there another way?*/

	cd->vd->GetWeights(hit, cd->vd->p, &weight);

	Vector coord = Vector(weight.wa + weight.wb, weight.wb + weight.wc, 0.0);

	return coord;
}

So first off I suppose I'm wondering: have I done anything horribly wrong or inefficient in the above code? That leads me to my next question: what is the best practice for loading an external texture (in this case Ptex)? I was not planning to build a Ptex file handler but instead to 'brute force' this and load the required Ptex images into a PtexCache in my InitRender() and use Ptex's getPixel() method to 'sample' directly using the coordinates I've generated. I have several concerns with this approach (do I need to consider MIP levels? even if my only goal is to bake the shader?). Unfortunately I don't even know enough to know whether they're valid concerns or not

Does anyone have a suggestion for an acceptable (not necessarily best) approach for doing this?

Finally, could anyone recommend additional avenues for getting up to speed on modern C++ more generally (this is the first time I've touched C++ since 2001) and the Cinema 4D SDK in particular?

@kbar it may be a long shot, but is it possible that the OBJIMPORTOPTIONS_SPLITBY setting in the OBJ importer is set to something other than By Object?

My script would only map the Ptex correctly in that mode. Here's the applicable section of Python I used for setting up the OBJ importer:

obj_loader = plugins.FindPlugin(c4d.FORMAT_OBJ2IMPORT, c4d.PLUGINTYPE_SCENELOADER)

if obj_loader:
    data = {}
    obj_loader.Message(c4d.MSG_RETRIEVEPRIVATEDATA, data)
    bc = data['imexporter'].GetDataInstance()
    bc.SetInt32(c4d.OBJIMPORTOPTIONS_SPLITBY, 3)

@kbar I was able to load OBJs from the Moana dataset in R20 using Python and the ids did align with the Ptex face indices. My method was fairly naïve: loop from face 0 up to the ptex file's faceCount and assume they align

Unfortunately I was using OpenImageIO bindings that I built myself and some of the Ptex files were coming in horribly corrupted. I posted about it to the oiio mailing list but got no responses. I found that solid color tiles might be the cause of the OIIO corruption of the Ptex files and posted an example here: https://drive.google.com/open?id=1z4N3xru0_TPRxVRDoCaQ7ODAUliJRfjM

In the above case the corrupted tiles should be solid white.

Eventually I gave up on solving this through Python + OpenImageIO. I'm trying to pick C++ back up to tackle Ptex but I haven't touched it in 20 years and it's slow going I finally managed to get Visual Studio to build the SDK examples

At any rate, I don't think there's an issue with the OBJ polygon ids in R20.

@bentraje I don't know exactly what issue you're facing, is this with the file I uploaded or another file?

The objects in the object manager are evaluated from top to bottom, so perhaps making sure the objects with the surface deformers are lower down the list than the object that they're referring to?

Thank you @m_magalhaes! I needed to open the plugins.sln solution instead of the project file. I feel like I've learned something, but I'm not sure what