Custom MaterialData UV & Parameter Bugs [SOLVED]

On 05/11/2014 at 06:10, xxxxxxxx wrote:

Hello,

when you double click on your material Cinema will create an new preview image. This preview image is created by rendering a simple scene. This scene is stored in the folder you mention above (resource\modules\xtensions\preview_scenes). To find out if the current render process is a preview rendering simply check the flag INITRENDERFLAG_PREVIEWRENDER.

The path to the original scene is stored in the given document's BaseContainer with the ID DOCUMENT_SECONDARYPATH.

  
  if(irs.flags & INITRENDERFLAG_PREVIEWRENDER)  
  {  
      if(irs.doc && irs.doc->GetDataInstance())  
      {  
          const Filename originalPath = irs.doc->GetDataInstance()->GetFilename(DOCUMENT_SECONDARYPATH);  
          GePrint(originalPath.GetString());  
      }  
  }  

Best wishes,
Sebastian

On 06/11/2014 at 01:18, xxxxxxxx wrote:

Hey Sebastian,

sorry for the late reply!

Your code snippet works great. My textures are found now

Open issues:
* Perfect sphere options and workaround for correct UV-mapping when OpenGL is enabled and when scene is rendered. As we discussed earlier there are hacks to accomplish it by turning the "perfect sphere" off, but I would like to see an official statement.

* Parameter-Update bug when OpenGL is enabled

Thanks,
Andreas

On 07/11/2014 at 07:06, xxxxxxxx wrote:

Hello,

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

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

We are currently working on a new MaterialData example for the SDK and want to publish is soon.

Best wishes,
Sebastian

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

Can I make a suggestion about your example? Or is it too late?

The current Materials examples don't show us how to make a material with only a couple of channels.
They either have no channels. Or all of standard the channels.
And it took me a while to figure out how to make a material with only a Color and Alpha channel because of that.

I also discovered that the checkboxes to enable/disable the channels are just ordinary generic gizmos declared in the .res file. Which I was surprised to discover.
Things like this are not currently explained very clearly, or at all, in the current MaterialData examples.

-ScottA

On 07/11/2014 at 11:26, xxxxxxxx wrote:

I would encourage too a very single addition "if possible" to the example, as I'm creating my renderer, I got 1 little thing to know about "material preview" , how they are rendered

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

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.

Looking forward to seeing the final example.

-ScottA

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

Hello,

The BaseChannel system is just a utility tool to organize a material. It is only used by the standard material so GetChannel() 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

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

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

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" /_>_

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"

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

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

Any progress in fixing the sphere preview yet?

-ScottA

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

Hello,

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

best wishes,
Sebastian

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

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 object have to be set. This can be done using CALC_TEXINFO:

  
             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

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

Excellent. That fixes it.
Thanks Sebastian.

-ScottA