Sampling color at vertexes

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

OK thanks.
I figured it out after looking closer at your code. I need to use Colors as the type not Vector.

I think I found a small typo:

Bool SampleColorAtVertices(BaseObject *obj) //Remo: 02.08.2014  
{  
  ...code  
  
  ConstUVWHandle uv_handle = uvw_tag->GetDataAddressR();  
  
  //Think it should be this  
  const UVWHandle uv_handle = uvw_tag->GetDataAddressR();  
  
  ..code

-ScottA

-Edit:
This is awesome Remo.
It seems to be working good for me so far in R13. I've been searching for how to this for years.
Thank you very much!!

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

ConstUVWHandle 

This is how it will be done in R15.

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

Ah. OK then.
I still haven't made the Jump to R15 yet. I had to change it in R13 for it to work.

Thanks again. This is really great.

-ScottA

On 02/08/2014 at 12:27, xxxxxxxx wrote:

I'm still on vacation but I will get back monday. Can't wait to try it out.
By the way (and I'm asking this without having seen the code Remo kindly provided), what if the object doesn't have UVW coordinates?

On 04/08/2014 at 10:26, xxxxxxxx wrote:

what if the object doesn't have UVW coordinates?
Then you can only use 3D Shaders.
But example code does not support this at this time and will exit with FALSE.
Another possibility would be to generate some UV and use it.
From point coordinates for example, or something like this...

On 04/08/2014 at 10:32, xxxxxxxx wrote:

Mmmmmm, so, lets say I have a cube (polygonal) without any UVW tag.
When I drag a material into it, it gets projected spherically, by default.
Lets us imagine that is a material with just a bitmap in the color channel.
Is it possible to sample the color that is at each vertex in this case?
Or must it be a shader?

On 04/08/2014 at 11:20, xxxxxxxx wrote:

Well then you will need to use ProjectPoint() function that I just added to the code.

https://github.com/PluginCafe/utilities-and-snippets/blob/master/C++/Remo/SamplerRemo.h

Not really tested, so if some one find a problem then please let me know.

On 04/08/2014 at 11:24, xxxxxxxx wrote:

I'm just finishing the custom .OBJ output code.
I will, hopefully, start the color projection code tomorrow. I will let you know how it goes. Very, very much in advance, Remo.

On 04/08/2014 at 13:41, xxxxxxxx wrote:

It's not working for me Remo.
It works fine in UWV mode. But the other modes are not returning the correct color values.
I'm still trying to figure out why.

The trouble seems to be coming from the for() loop under: /// Sample using vertex position and uv.

-ScottA

On 04/08/2014 at 14:08, xxxxxxxx wrote:

This is probably because no data form TextureTag was used.
New ReadTextureTag() function may fix this.

On 05/08/2014 at 14:11, xxxxxxxx wrote:

I have changed all the Int32 to LONG, all the FLOAT to float, all the GetInt32 to GetLong, all the GetFloat to GetReal.
I also had to define PI and PI2
But now I also stumbled on:

maxon::BaseArray<Colors> colors;

I noticed that Scott also stumbled there but from your conversation I could not figure out how to make it work?
Have you managed to update all the code to R13, Scott? Could your R13 version work on my R14 code?

On 05/08/2014 at 14:50, xxxxxxxx wrote:

I used a GeDynamicArray Rui.
A Vector is faster. But I prefer to use GeDynamicArray whenever I can so Mac uses can also use my code too. I try to only use Vectors when I need top speed from my arrays. And in this case I don't need a very fast array.
Most R13 C++ code works in R14 and R15. Which is why I'm still coding in R13.

I replaced this in Remo's code

    maxon::BaseArray<Colors> colors;  
  colors.Resize(pcnt);

With this R13 compatible code
Note: Don't forget to put #include "ge_dynamicarray.h" at the top of the code.

GeDynamicArray<Colors> colors(pcnt);

To print the color results I change Remo's print code to this

    //Print the results   
  for(LONG i=0; i<pcnt; ++i)  
  {  
      //GePrint(RealToString(colors[i].sampled));  
      GePrint("VertID:" +LongToString(i) + " R:" + RealToString(colors[i].col.x) + " G:" + RealToString(colors[i].col.y) + " B:" + RealToString(colors[i].col.z));  
  }

It works fine for UWV mode.
But I have no idea how to make the new ProjectPoint() stuff work though.
I have no clue what Remo is doing or talking about with that code.

-ScottA

On 05/08/2014 at 15:20, xxxxxxxx wrote:

Thank you very much, Scott. It is returning no errors now.
Now I have to make my code work with it. Still a lot to do.

On 05/08/2014 at 16:31, xxxxxxxx wrote:

As it is now, it crashes.
I'm calling SampleColorAtVertices(b_source); and "b_source" is an object that I get from a Link field, with:

BaseObject* b_source = (BaseObject* ) data.GetObjectLink(PPT_SOURCE,doc);

This object contains a material tag with a simple Checkerboard shader in the color channel.
As soon as I execute it, it crashes

On 05/08/2014 at 17:11, xxxxxxxx wrote:

Does it crash if you use the code on an object that's not in your link field?

If not. Then maybe you need to fill in the other LF parameters. I'm not sure if they are required or not.
BaseObject *linkedObj = (BaseObject* )bc->GetLink(obj, doc, Obase);

-ScottA

On 06/08/2014 at 02:15, xxxxxxxx wrote:

Yes, it does crash even with an object that I get from:

BaseObject* b_source = doc->SearchObject("Cube");

On 06/08/2014 at 04:53, xxxxxxxx wrote:

Well now I am trying to use Int32 and Co even in R14 code.
One can simple invert "legacy.h" for older C4D API versions.

Like this:

  
    
    
    typedef LONG Int32 ;
    typedef ULONG UInt32;

>Yes, it does crash even with an object that I get from:
How and where does it crash ?

Is the object attached to the document ?

Remo

On 06/08/2014 at 05:43, xxxxxxxx wrote:

Yes, the object is in the document, created manually, so it is live.
I have the call to your routine inside the Message method (it is invoked by pressing a button).
I simply get the object and call your routine to print out the color samples of the vertexes.

On 07/08/2014 at 06:24, xxxxxxxx wrote:

This is strange.
I have done some simple test and it work fine on R15.
Could it be that there are some problems with back porting to R13 ?
By the way the older code that worked for R13 is still there in git history.

On 07/08/2014 at 11:40, xxxxxxxx wrote:

I tried searching for it and indeed I found it.
But it lacks a lot of the stuff that is on the latest version and I can't even start to figure out a way to make it return the average color of vertexes