Cpct?

[EgonOlsen]

Yeah, but Primitives don't really have proper texture coordinates. That's the point of ExtendedPrimitives. I suggest to port that too to have something that helps to limit the possible problem sources.

[AGP]

OK, done. Same thing: single-colored textures work, images don't (and the images aren't null, either).

[EgonOlsen]

Then either your loading/conversion of the texture is wrong or your texture coordinates are. I tend to the former, because that's more likely to get broken in porting then some simple floats that should behave the same in both languages.

[AGP]

Loading an image is a simple call to Image.FromFile(filename). Which leaves us the texture coordinates. Would that be in Object3D?

[EgonOlsen]

Loading an image is a simple call to Image.FromFile(filename). Which leaves us the texture coordinates. Would that be in Object3D?

Are you sure? Loading is one thing, but you have to make an int[]-array out of the loaded image. I would rather think that this step is wrong.

[AGP]

I applied my ReverseBytes to the texels and still got black. Actually, at first I got fully-transparent, then I switched the bitwise OR for a bitwise AND for alpha as follows and I was back to black.

Code Select Expand


private static System.UInt32 ReverseBytes(System.UInt32 value) {
    value = (value & 255);//MAKE OPAQUE IT's AN OR IN SoftGLRenderer. WHY?
    return (value & 0x000000FFU) << 24 | (value & 0x0000FF00U) << 8 | (value & 0x00FF0000U) >> 8 | (value & 0xFF000000U) >> 24;
}
    }


[AGP]

You're a good man, Egon. You were right, the texels[] were black. I'm forced to use the following rather slow nested loop, but voilá, it works.

I think that I'm going to tackle a skeletal structure for it before I try my hand at a hardware renderer, but the eventual C# hardware renderer will benefit from direct access to OpenGL.

Code Select Expand


    int i = 0;
    for (int y = 0; y < image.Height; y++)
for (int x = 0; x < image.Width; x++)
     texels[i++] = (uint) image.GetPixel(x, y).ToArgb();


[AGP]

Skybox.render() is making my forest pink (not calling SkyBox.render, naturally, sees my forest green although the sky looks appropriately blue--and it doesn't escape me that blue+green=pink), for some reason. Have you any direction you might give me?

[EgonOlsen]

Do you have a screen shot?

[AGP]

Without SkyBox:
https://www.dropbox.com/s/dy5aird4uw22a3p/Forest_NoSkyBox.jpg?dl=0

With SkyBox:
https://www.dropbox.com/s/y8wqt06phx73ol1/Forest_SkyBox.jpg?dl=0

[EgonOlsen]

What the hell...is that actually using the software or the hardware renderer?

[AGP]

I only ported the software. I haven't decided which way to go with hardware yet.

[EgonOlsen]

I'm not sure what I'm seeing there then. If somehow looks as if you are rendering parts that should be hidden by the alpha channel. Like as if the texel sampled to deal with alpha doesn't match the one of the actual color value. But I don't see how that could happen nor do I understand what this has to do with the skybox. Inwould create a simpler test scene and try to narrow it down to what actually triggers this behaviour. In this complex scene, it's a little hard to tell.

[AGP]

What calls init(boolean ok, int x, int y)?

[EgonOlsen]

In which class?