Custom MaterialData UV & Parameter Bugs [SOLVED]

Helper

On 08/11/2014 at 02:10, xxxxxxxx wrote:

Hey Sebastian,

to support perfect spheres and also different projection types set in the Texture Tag you have to set the VOLUMEINFO_EVALUATEPROJECTION flag in GetRenderInfo().

You are right, that this solves the uv-mapping of the parametric spheres without turning the "render perfect" off. But it breaks my material preview. When I use the VOLUMEINFO_EVALUATEPROJECTION flag my material preview still shows my diffuse color, but as soon as I load a texture, the preview becomes completely black, when I remove my texture, it shows the diffuse color again and seems to work.
EDIT: I debugged it and this call in CalcSurface() :

m_pDiffuseTexture->GetPixel(x, y, &r, &g, &b);

always returns 0, 0, 0 for r, g, b when the render call is made for the preview.

When you use InitGLImage() you have to set the filled bitmap dirty using SetDirty(). This will trigger the update.

NICE! It works! For everyone else:
In: Bool MyMaterial::InitGLImage(BaseMaterial* mat, BaseDocument* doc, BaseThread* th, BaseBitmap* bmp, Int32 doccolorspace, Bool linearworkflow)

when you have set your pixels (in my case fetch a texture and multiply a color value) simply call:
bmp->SetDirty();
in addition to the call, already in my sample:
EventAdd();

I will close the other related thread and set it to solved. In this one we still have some issues with the preview and the projection evalutation.

@MohamedSakr:
My sample project available at the top shows how to create the preview. I copied it from one of the examples. As you might have noticed, there are still bugs in it.

Bye,
Andreas

Helper

On 08/11/2014 at 11:16, xxxxxxxx wrote:

In my R13 version. I didn't use GetRenderInfo().
If I add that to my code. And set the VOLUMEINFO_EVALUATEPROJECTION flag. It does fix the render perfect problem. And displays the image correctly in the editor window even when rendering.

However. It also breaks the material preview image.
It turns it into a bright glowing white color. Confused

Looking forward to seeing the final example.

-ScottA

Helper

On 10/11/2014 at 02:30, xxxxxxxx wrote:

Hello,

The BaseChannel[URL-REMOVED] system is just a utility tool to organize a material. It is only used by the standard material so GetChannel()[URL-REMOVED] will only work with the standard material.

If you use the metaphor of "channels" in your material is up to you. In the resource file of a material plugin you can define different groups that allow you to organize your parameters. Take a look at the "Cheen" material to see how each group controls a completely different aspect.

Using and customizing the material preview is a large topic. For the most simple case just add "INCLUDE Mpreview;" to your res file and the preview itself will handle the rest. If you have any specific questions please open a new thread so the topics don't get mixed up.

Best wishes,
Sebastian

[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

Helper

On 10/11/2014 at 03:01, xxxxxxxx wrote:

Hi Sebastian,

Using and customizing the material preview is a large topic.

That should not be a large topic in the API... it's just a small image of a single render pass^^

Have you tried to use the VOLUMEINFO_EVALUATEPROJECTION flag in my sample project? Have you tested it with spheres? Can you verify that the preview is broken because the GetPixel() returns 0, 0, 0 for the fetched color (like I described above)?

I'm really interested how those interactions can happen in the API. The evaluation of a projection of UV-coordinates has nothing to do with a bitmap. Why in the world is there a difference WHEN and WHERE I fetch texels from a bitmap. This makes absolutely no sense and should be tackled!

Thanks,
Andreas

Helper

On 11/11/2014 at 00:55, xxxxxxxx wrote:

Hello,

if the given x/y coordinates are outside the dimensions of the given BaseBitmap, GetPixel() won't do anything and will not change the given r,g,b values. You should check if the x/y coordinates based on the UV-settings are valid.

I uploaded the simple material example. It may be included in the SDK.

MaterialData example (ZIP)

Best wishes,
Sebastian

Helper

On 11/11/2014 at 09:10, xxxxxxxx wrote:

Thanks for the sample! You are right that the uv coordinates of my objects where greater than 1.0. I really don't know why... this again makes no sense at all because the uvs should be the same independent of the "evaluate projection flag". The mapping looks exactly the same in the preview... but whatever, using this code in CalcSurface() works now:

float integral = 0.0f;
float u = modf(vd->uvw.x, &integral);
float v = modf(vd->uvw.y, &integral);		
  
Int32 x = static_cast<Int32>(m_pDiffuseTexture->GetBw() * u); 
Int32 y = static_cast<Int32>(m_pDiffuseTexture->GetBh() * v); 
  
UInt16 r = 0;
UInt16 g = 0;
UInt16 b = 0;
m_pDiffuseTexture->GetPixel(x, y, &r, &g, &b);

There is only one singe bug in here:
1. Enable OpenGL
2. Create a Null-Object
3. Create a parametric sphere (do not make it editable!)
4. Make the sphere a child of the null object
5. Create MyMaterial (download still up there in the post) and select a texture for the diffuse/color channel
6. Assign it to the Null-Object (the parent of the sphere!)
7. Select the sphere (child!) and move it

The result is, that the uv-mapping changes depending on the position of the sphere relative to the parent (null-object). It seems that the mapping is only correct, when the sphere is exactly at the origin/center of the parent.

See here:
_<_img src="https://dl.dropboxusercontent.com/u/15216944/c4dforum/materialbug_opengl_renderperfectsphere_parent_movefromcenter.png" height="239" width="997" border="0" /_>_

Helper

On 11/11/2014 at 10:45, xxxxxxxx wrote:

this is a normal behavior!! , I tested it with standard material and it does the same!!!!

edit: this is a CONFIRMED bug, when I render, it renders correctly "OpenGL got a problem here" , it renders correct because it uses UVs , not spherical projection "like OpenGL"

Helper

On 16/11/2014 at 10:44, xxxxxxxx wrote:

@Sebastian.
There seems to be a problem in your example.
When you choose to use a shader. And you load an image into the shader. The preview icon is white.
This only happens with the sphere preview option.

I just ran into this same problem when writing my own R13 material plugin.
And I discovered that if I Shift+LMB on the sphere in preview window and rotate it 180 degrees in X. The image shows up properly.
So I guess we need a way to either show both sides of the sphere. Or some way to see the other side of the sphere in the material's preview window?

-ScottA

Helper

On 21/11/2014 at 11:38, xxxxxxxx wrote:

Any progress in fixing the sphere preview yet?

-ScottA

Helper

On 24/11/2014 at 10:57, xxxxxxxx wrote:

Hello,

I have not found a solution for this particular issue yet.

best wishes,
Sebastian

Helper

On 24/11/2014 at 11:43, xxxxxxxx wrote:

OK. Thanks for the update.
At least I know now that it's not something I'm doing wrong.

-ScottA

Helper

On 28/11/2014 at 02:18, xxxxxxxx wrote:

Hello,

in the standards preview scene the Texture Tag tiles the U coordinate. This way coordinates bigger than 1 are created. So a material must handle such coordinates. To make sure a shader will handle this properly the texture flags in the ChannelData[URL-REMOVED] object have to be set. This can be done using CALC_TEXINFO[URL-REMOVED]:

  
             ChannelData channelData(vd);  
             channelData.texflag = CALC_TEXINFO(((TexData* )vd->tex)->texflag, CHANNEL_ANY);  
  
             resultColor = _renderParamShader->Sample(&channelData);

For further questions on materials please open a new thread. Thanks.

Best wishes,
Sebastian

[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

Helper

On 28/11/2014 at 07:43, xxxxxxxx wrote:

Excellent. That fixes it.
Thanks Sebastian.

-ScottA