clipka <ano### [at] anonymousorg> wrote:
> 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.

Thanks.
I will sort this out.

I want to keep the possibility of including files written by hand.
Blender does not allow me to establish. Example: the slope_map.
Probably, I will try to add a my GUI texture editor.
But it is a task that must be performed after.
:)

Post a reply to this message