Thanks for all the tips @ferdinand
The solution was Catalina + XCode 12.4
Thanks for all the tips @ferdinand
The solution was Catalina + XCode 12.4
Ok, didn't know about that, will try.
But on Catalina, projects are building with XCode 11.
Installing XCode 12.4 right now to be able to make them universal....
@ferdinand said in Error building R25 macOS - TypeTraitExpr:
Are you sure you are building with the legacy build system?
if you mean to ask if I'm using the maxon_api, I'm not. My plugin contains camera effects, post-processing, and tags.
You said this an old project, can you go back in your version control and see if the old version does build?
no, it doesn't.
but neither the cinema4dsdk
project builds
Have your tried replacing your frameworks with a 'fresh' batch from an R25.0 sdk.zip, in case you somehow 'tarnished' your current ones?
yes, my R25.015 environment was failing, then I created a new one with R25.121, and see the same errors happening, on my plugin and on the cinema4dsdk
sample project
It could be the OS.
This is the only difference from the last time I had to build it, in 2021, I stuck to Catalina for a long time, only upgraded recently.
Anyway, my old macbook is requiring an upgrade for a long time. Will try Catalina on it...
Hello,
I added a little feature to my plugin, built it for R23 (which works on R24) and 2023, but am am unable to build the frameworks for R25.
The same plugin was built successfully for R23 with XCode 12
My R25 project is the same project sitting on my desktop since my last successful build. No new frameworks or anything.
I tried regenerating sources and projects, all the same error.
I always build the cinema4dsdk
project as a baseline to make sure everything is working, and it also gives the same error.
my setup...
macOS 13.5.2
XCode 12 / 13
R25.015 / R25.121
In file included from /Users/roger/Dev/C4D/SDK/C4DSDK/R25.121/frameworks/core.framework/source/maxon/weakref.cpp:2:
In file included from ../source/maxon/weakrefservices.h:4:
In file included from ../source/maxon/interfacebase.h:6:
../source/maxon/datatypebase.h:1828:57: error: cannot yet mangle expression type TypeTraitExpr
template <typename T> Result<typename std::conditional<STD_IS_REPLACEMENT(same, T, Data) || (GetCollectionKind<T>::value == COLLECTION_KIND::ARRAY), T, typename ByValueParam<T>::type>::type> Get() const
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /Users/roger/Dev/C4D/SDK/C4DSDK/R25.121/frameworks/core.framework/source/maxon/weakref.cpp:1:
In file included from ../source/maxon/weakref.h:4:
In file included from ../source/maxon/atomictypes.h:4:
In file included from ../source/maxon/private_atomic_core.h:8:
In file included from ../source/maxon/apibase.h:67:
../source/maxon/utilities/compilerdetection.h:303:70: note: expanded from macro 'STD_IS_REPLACEMENT'
#define STD_IS_REPLACEMENT(name, ...) STD_IS_REPLACEMENT_HELPER(__is_##name, __VA_ARGS__)
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
<scratch space>:140:1: note: expanded from here
__is_same
^
Ok, but if RS can call it, when and how does it?
Call just once... makes no sense, because the effect calls once per pixel at least, on every frame.
Why would RS call it in a different context?
What do you mean not fully functional?
Is it partially functional?
How so?
Hey @Manuel ,
Do you mean RedShift is compatible with C4D lens effects?
Can I really use CreateRay() with RedShift?
I have a lens plugin that works well on the standard renderer but not on the RS camera.
Is there anything extra to do to enable it on RS?
Thanl you,
Roger
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
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
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
, the other I sent was missing the Maya comparison.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.