Just found my problem, nothing to do with the drawing API...
bd->SetDrawParam( DRAW_PARAMETER_SETZ, DRAW_Z_ALWAYS );
It was setting the depth fragment on all the strands, occluding itself sometimes!
Just found my problem, nothing to do with the drawing API...
bd->SetDrawParam( DRAW_PARAMETER_SETZ, DRAW_Z_ALWAYS );
It was setting the depth fragment on all the strands, occluding itself sometimes!
@pyr You can have both. GetVirtualObjects()
is called first, and if you return nullptr GetContour()
is called.
But you need to register your object with OBJECT_GENERATOR | OBJECT_ISSPLINE
.
In R20, it changed to id[0]._descId
Hi,
I've always rendered my splines with Hair materials. After adding some custom modifiers, I simply cannot render anything anymore. Again, let's dive into old forum topics and start making tests to try and learn how things work.
At first I learned that the relationship between GetContour() and GetVirtualObjects() has always been a hot topic, not mentioned anywhere in the docs. I discovered that by sending nullptr to GetVirtualObjects(), it will eventually try GetContour(). Because I have OBJECT_GENERATOR and OBJECT_ISSPLINE defined, to generate either a poly or a spline, based on parameters chosen by the user.
About spline and deformers, here's what I discovered...
So... looks like the Hair material does not render modified splines. Why? Is that a limitation or a bug?
But the C4D native hair has a Deformers flag that enables rendering of the deformed splines. How can it do it? I need that too!
EDIT: Some curious findings about C4D Hair object...
@r_gigante , some details of what happened here, that looks like a dependency issue on kernel_app_64bit.exe...
When you just start kernel_app_64bit.exe from External\Maxon\Cinema4D\ProjectTool\cinema4d_r20_project_tool_20180906 on the agent, you get an error "missing libmmd.dll"
And Dependency walker shows that indeed the .exe depends on that dll and it cannot be found
It looks like this dll was installed by someone on the agent, but the 1809 update removed it (Win10 updates are known for removing applications they consider "incompatible")
I opened kernel_app_64bit.exe in a dependency walker on my machine and found that I get that libmmd.dll from some common Intel installation, probably of some drivers
Then I wondered how Maxon expected the tool to run when it depends on a .dll that is not commonly included in Windows, and indeed I found that the dll is placed in resource\libs\win64 under the .exe
But for some reason the .exe won't pick the .dll from that directory, and the fact that it happens to run on some systems is that they already have the dll installed by another appI now copied libmmd.dll from resource\libs\win64 to the directory of the .exe and it ran fine from Windows Explorer, let see if the TC build will work. The TC build succeeded
I think MAXON should check why kernel_app_64bit.exe doesn't pick the dll from resource\libs\win64
Now we have to move .dll to the directory of the .exe in our Svn repository as well (which is not how it is distributed by Maxon), to make fresh installs work too
@m_adam , AddEventNotification
was exactly what I needed. I created a notification to NOTIFY_EVENT_UNDO
, and then add my object to it. Now if I delete anything from my object after a polygon is deleted, it will be restored with Undo.
Thanks!
case MSG_NOTIFY_EVENT:
{
CHECK_BREAK( data != nullptr );
const auto eventData = static_cast<NotifyEventData*>( data );
if( eventData->eventid == NOTIFY_EVENT_UNDO )
{
NotifyEventMsg* notifyMessage = static_cast<NotifyEventMsg*>( eventData->event_data );
CHECK_BREAK( notifyMessage != nullptr );
if( notifyMessage->msg_id == Int32( UNDOTYPE_DELETE ) )
{
eventData->doc->AddUndo( UNDOTYPE_CHANGE, Get() );
}
}
break;
}
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...
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