Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - GeMeMe

Pages: [1]
1
[C4D] Bug Reporting / Re: Corona Bitmap/Bump map problem
« on: 2024-07-24, 09:25:15 »
Thanks for confirming, burnin.
This has to be a bug introduced in a recent version, right? I can't imagine such a fundamental problem being there longer without anyone noticing.

2
That would make it impossible to use the rotation feature of the Mapping Randomizer for any material with normal maps. No, the Mapping Randomizer should compensate for this rotation by rotating the normal vector accordingly, which is what it does with Corona/3ds Max. That's why it is so important to put the Mapping Randomizer AFTER the Normal shader, not between the normal map and the Normal shader. Instead, the correct setup behaves exactly like the incorrect one.

3
That's how it should work - and does so in 3ds Max. Not so much in C4D, unfortunately.

4
Somebody, please? At this point, I really only need to know who's problem this is. Am I doing it wrong, or is this something the devs should have a look at? Same goes for my other bug report.

5
[C4D] Bug Reporting / Re: Corona Bitmap/Bump map problem
« on: 2024-07-23, 15:38:28 »
Somebody, please? At this point, I really only need to know who's problem this is. Am I doing it wrong, or is this something the devs should have a look at? Same goes for my other bug report.

6
Hi again,

Just ran into another issue: Using the Mapping Randomizer shader to rotate the output of a Normal shader causes the normal information to get corrupted. It appears, the normal information is not correctly rotated to compensate for the map rotation applied by the Mapping Randomizer. This looks exactly like when wrongly inserting the Mapping Randomizer BEFORE the Normal shader. Can anyone confirm, please? If it's me who's doing things wrong, please let me know. Thanks!

7
[C4D] Bug Reporting / Corona Bitmap/Bump map problem
« on: 2024-07-20, 14:49:34 »
Hi everyone,

I've run into a problem with bump mapping, of all things. A simple Corona Bitmap bump map, connected to the bump slot of a Corona Physical material should produce the output in the first image. The second image shows what I get instead. The normal vector calculation is off; the y-component seems to be inverted.
If I exchange the Corona Bitmap shader for a simple Bitmap shader, the bump effect is rendered correctly (this is how I got the first image). This seems to indicate that there is some problem with the way Corona Bitmap is sampled. Can anyone confirm?
I certainly hope that it's just me missing something obvious, instead of there being something seriously wrong with Corona for C4D. If so, please point me to my mistake.
Anyway, and feedback is appreciated!

8
Thanks, James. Coming myself from 3ds Max, I'm also more familiar with maxscript. I definitely have my gripes with maxscript here and there, but looking into C4D scripting, I now come to a whole new appreciation regarding the ease with which something like building material and shader trees works in 3ds Max...

I was under the impression that the Corona plugin bypasses C4D's node graph engine, hence the need for their own node editor (not sure which came first). I think, unless one of the Devs chimes in, we won't be able to get to the bottom of this.

I guess I have to pivot towards a template-based system for batch creation of materials.

9
Thanks for looking into this, James. Let me know what you find out! I'll continue my own experiments in the meantime.

10
Thanks for taking the time, James.
Quote
can you not just assign the color node to a variable then use that throughout

You cannot, unfortunately. Although, it seems like it does work at first. The node editor shows the shader correctly connected to both materials, but only first material (the one that is the parent of the shader) is able to actually use its output. new_corona_mat2 behaves like the shader is not connected at all.

The c4d.BaseList2d documentation states:
Quote
  • If you are programming shader links you need to make sure that every shader is referenced only once; it is not allowed that a shader is referenced multiple times.
  • If the referencing object is a shader the referenced shader must be a child of it, otherwise it must be inserted via InsertShader().
  • Example 1: A tag references a shader. The shader must be inserted into the tag using tag.InsertShader().
  • Example 2: A shader (A) references another shader (B): shader B must be a child of shader A.

I assume that's why Corona's node editor uses an intermediary node, along with some under-the-hood workings to pull off shared shaders. How this actually works is what I'd like to find out.

11
Hi everyone,

I literally started looking into C4D and Python yesterday. So please forgive if I don’t quite hit the right terminology here and there.

I’m setting out on integrating C4D into an existing toolchain via Python. Part of that is the need to create materials with complex shader trees from scratch via code only. I’m already at a stage where I can import the material config via JSON, create and connect material and shader nodes, as well as set all their parameters. But I’ve run into a problem that I didn’t foresee.

As I’ve learned, every shader node MUST be a child of the material/shader it is linked to and CANNOT be used as input by other materials/shaders that are not its parent. I wish to create material setups where the output of some shaders is reused by more than one other shader or material. Corona’s node editor solves this problem by automatically introducing invisible “shared nodes” between a shader output and its multiple users. When I probe a simple material I created via the node editor, I see something like this (A “Corona Physical” material with a single “Color” shader assigned to two different inputs):
Code: [Select]
BaseMaterial <c4d.BaseMaterial object called Test material/Corona Physical with ID 1056306 at 2107176123328> {
  Slot 20209: # Roughness
    Node <c4d.BaseShader object called Color1 (shared)/Corona Shared with ID 1040749 at 2107176157248> {
      Slot 11901:
        Node <c4d.BaseShader object called Color1/Color with ID 5832 at 2107176140352> {
        }
    }
  Slot 20218: # Bump
    Node <c4d.BaseShader object called Color1 (shared)/Corona Shared with ID 1040749 at 2107176148800> {
      Slot 11901:
        Node <c4d.BaseShader object called Color1/Color with ID 5832 at 2107176159296> {
        }
    }
}

This seems to indicate that the node editor internally actually does create duplicates of a reused shader node with a “Corona Shared” node for each (note the different memory addresses), and then uses some mechanism to keep these duplicates in sync, while presenting only one shader node to the user in the node editor. This makes sense as even a Corona Shared is subject to the one-parent-per-child restriction of c4d.BaseList2D().

So how does this all work under the hood? How can I create a material using this sharing mechanism when creating materials via Python? I looked far and wide for some sample code or explanation but found nothing. So, I really hope some Dev or other knowledgeable person will shed some light on this or at least point me in the right direction.

Any help is greatly appreciated!

Pages: [1]