Posts made by rsodre

Thanks @ferdinand, I think that clarifies my issue. I'll what I can do here.

Hello,

Is there any way to multiply the bounding box of an ObjectData::GetDimension() with an arbitrary transform?

I get that the bounding box is always multiplied by the object's global matrix, but our workflow allows us to display a modifier at an earlier stage, where it should have a different global matrix. I can fix the object's display with BaseDraw, but it the bounding box ignores it.

An an example, I corrected this object object display on BaseDraw to move it to the upper plane, but the bounding box is still attached to the bottom plane.

Thanks,
Roger

@m_magalhaes Ok, is it going to be fixed on the bug report or is that a limitation we have to live with?

@m_magalhaes Difference between the viewport uvs and render uvs.

This is the render, it is correct now, with uvs from 0..2:

But the material rendered at viewport does has normalized uvs (0...1):

@m_magalhaes Thank you, that works.
It would be super useful to have this piece of information on the Output() reference.

What about having the correct uvw on the viewport, is it possible?

Hello,

I need to access uvw coordinartes outside of the 0-1 boundary, in a ShaderData.
In UV Edit mode, I scaled plane's uvw to go beyonx 1,1, but the coordinates passed to ShaderData.Output() always normalized to 1,1.

How can I access the actual uvs I need?
Maybe some trick on material tag?
Some external renderers use this workflow for UDIM textures, so it looks possible.

My plugin is in C++ but, but I made a simple test plugin and it has the same issue...
Py-ShaderUvw.pyp

def Output(self, sh, cd):
	c = c4d.Vector( cd.p.x, cd.p.y, 0 )
	return c

Here's how the UVW is setup, the viewport uvws are repeating...

Confirming that the UVW tag contains coordinates up to 2.0...

And the actual render is even stranger, it makes no sense...

Thanks, seems to be working now, thanks.

This renders the texture on the object and material preview, nd solved all my problems
Note that this call is very different from the recommended on the TEXTURE reference (needs update).

bool FindTextureFullPath( BaseDocument* doc, const String& textureName, Filename& result )
{
	if( GenerateTexturePath( doc->GetDocumentPath() , Filename( textureName ), Filename(), &result ) )
		return true;
	return GenerateTexturePath( GetActiveDocument()->GetDocumentPath() , Filename( textureName ), Filename(), &result );
}

Hi,

I'm building a ShaderData plugin, that at first just reads a TEXTURE parameter, extracts a BaseBitmap from it on InitRender() and samples it on Output(). I added it to a material's Color Texture, but the result is strange.

As I understand, the TEXTURE resource parameter is internally a STRING. When I get from the node, it contains only the file name, not the path. Then we need to use GenerateTexturePath() to find out where it is.

How can we resolve a texture that is not on the same path as the project, as the parameter does not know where it came from?

In my case, the texture IS o the same folder.
The attribute preview works, it can sample the texture.
The material's Texture shader link preview also works.
The material preview doesn't, it does not find the texture.
And objects in the scene using the material also do not get the texture.

What's missing here?
This is how I get the texture path:

sh->GetParameter( textureParamId, data, DESCFLAGS_GET_0 );
const auto textureName = data.GetString(); // This returns only the file name, not the path
auto doc = sh->GetDocument();

Filename textureFullPath;
GenerateTexturePath( doc->GetDocumentPath() + doc->GetDocumentName(), Filename( textureName ), Filename(), &textureFullPath );

Thanks,
Roger

Thanks, @zipit that's very clarifying.

Hi @zipit

Yes, both do different things, but because I want to understand which one is correct, if any, when initializing the object inside NodeData::Init().

My custom user data does not have UI and is not available to be added manually on the object's UserData menu, so it didn't pass in my mind to look there. I declare them inside ID_OBJECTPROPERTIES of the res file.

I rarely access data directly from the node's data container, other than in NodeData::Init(). I usually use SetParameter() and GetParameter(), with the proper DescId levels. From your answer I understand that I will be retrieving the second snippet's data later with GetParameter(), correct?

If I do not initialize at all, peeking at the data container after I use SetParameter(), user data are inside a 700 container.

Hello,

What is the proper way to initialize user data in a BaseContainer?

bc->SetData( paramId, GeData( MY_CUSTOMDATATYPE, DEFAULTVALUE ) );

...or...

auto userDataContainer = bc->GetContainerInstance( ID_USERDATA );
userDataContainer->SetData( paramId, GeData( MY_CUSTOMDATATYPE, DEFAULTVALUE ) );

I always used the former, but noticed a BaseContainder inside NodeData::Read() formatted like the latter.

We found another AA option on Settings, Viewport Hardware, that performs much better than the View Settings Supersampling, probably using a different technique.

Thanks.

@r_gigante I just want to let you know the tester's feedback...

I don't understand what they mean! Because in Maya - I use 16x16 supersampling in AA options and everything is smooth like in cinema4d with 16*16 supersampling. But! In Maya I have 120-200fps Why in Cinema4d - I have 1 fps with the same quality? Why? Can they explain this? Do they check my video with Maya's performance?

The video he mentions is this one, the other I sent was missing the Maya comparison.
Our plugin is also available for Maya, so it's impossible to avoid comparisons.

And I have to agree with this one. If the 16x16 Supersampling is mathematically impossible to work with, it shouldn't there. And how can others do it?
I think there must something wrong with the viewport Supersampling.

Thanks @r_gigante.

Hello,

Occasionally we have reports about the performance impact of increasing Viewport Settings Supersampling, a very popular feature to increase quality when working with hair strands.

One tester made this video comparing Maya and C4D. Even without Redshift, enabling Supersampling on an empty C4D scene decreases the performance rapidly.

None: 1000 fps
2x2: 66 fps
4x4: 16 fps
8x8: 4 fps
16x16: 1 fps

Is there something we can do to make supersampling usable or is this a bug?

Thanks,
Roger

@r_gigante yes, I tried that version and no luck as well, but it looks like a USD issue to me.
The USD team didn't give much hope for helping with this.

I've built my usd static library using pxr_Custom as internal namespace to identify on the call stack. This screenshot shows the call stack, looks like it's trying to load C4D's dynamic lib instead of the included static. Thats why I don't think it's tbb issue.

I have the issue isolated on a simple plugin, and if I link to C4D's dynamic usd, instead of our built monolithic static, the simple plugin seems to load and work. I will try to do the same on our environment...

But this will be a super specific ugly exception on the build pipeline. If we could fix and make the plugin use its own included static version of USD would be much easier. The simple plugin is here, if you could check.
To test the project, just run C4D from Xcode and it will freeze loading the plugins.
You can add ../install.sh as a Run Script Phase to fix library paths and deploy. (I wish I could add the Run Script Phase from project tool... )

This issue is not solved yet.
I'm just disabling customo USD features on R23 for the moment.

I have not tried @kbar suggestion. The TBB team does not recommended to link statically, and my team agrees.

Talking about this... since R22 the Outlines and Boundign Box options have been removed from View Settings.
Where has it gone???