Am 04.11.2016 um 20:26 schrieb LanuHum:
> Why not add the name of the texture in texture.h to use options?

Because it's entirely irrelevant for the render engine.

> Your text:
> struct Texture_Struct: public Pattern_Struct
> {
>      TextureBlendMapPtr Blend_Map;
>      int References;
>      TEXTURE * Next;
>      string name; // Add your code !!!!!!!!!!!!!!!!
> 
> 
> It will not affect the code, but it allows you to manipulate using povray as a
> library...

It will waste memory, adding 40(!) bytes of overhead per texture
(Windows 64-bit binary; other platforms may vary) even if the name is
unused.

Even a C-style string (char*) would add 8 bytes of overhead (again
Windows 64-bit binary).

As I sad before, such a name is entirely irrelevant during rendering.


Also, if the string is intended to reference textures by name, it would
be pretty inefficient to store that information in the texture itself,
as to find a texture you'd have to visit all of them and compare the
string. It would be much faster to store the name->texture mappings in a
separate data structure optimized for such purposes, e.g. a hash map or
a search tree.

And such a data structure wouldn't have to be part of the render engine
anyway: It could easily be set up and managed by whatever program
intends to feed the render engine with data.

The reasons why you're running into so many complications is that you're
trying to somehow shoehorn your Blender-to-POV-Ray bridge into the
existing parser, rather than bypassing the parser entirely.

Post a reply to this message