Automated creation of textures?

[Petri]

Boy, do I have plenty of questions these days...

Is it possible to automate the creation of textures with VS?

If I have a bunch (like 3000) colour samples as JPG-files, can they be converted to textures? I could have a text file of the names I want to process.

The texture type would be "Image Color".

[islandmon]

Photoshop > Batch processing was utilized to create these textures:

Dupont Zodiac textures

CambriaStone textures

[Petri]

Yes, but I'm interested in getting images into VW, ie. creating the textures from an images.

[Rick Francken]

...Is it possible to automate the creation of textures with VS?

If I have a bunch (like 3000) colour samples as JPG-files, can they be converted to textures? I could have a text file of the names I want to process.

The texture type would be "Image Color".

Petri,

It is possible, but...there are some things I haven't figured out yet. The main one is how to do it silently, ie., without dialogs showing for each image.

Here's what works so far. First create the Texture. Then use the texture handle to create the shader record. Then use the Shader Record handle to create the Texture Bitmap.

var

hTexture, hShader, hBitmap: handle;

begin

hTexture:= CreateTexture;

{if the texture handle is not nil create the shader record }

if hTexture<>nil then

hShader:= CreateShaderRecord(hTexture, 1, 15);

{NOTE: 1 in this case means Color shader record family, 15 means Wrapped Color Image prototype, as defined in the Vectorscript Function Reference.}

if hShader<>nil then

hBitmap:= CreateTextureBitmapN(hShader);

{NOTE: From what I have found so far, the "CreateTextureBitmapN" function and the "CreateTextureBitmap" function are the only ones that give a valid texture bitmap, and I was hesitant to use CreateTextureBitmap because it is marked as obsolete.}

end;

If you have references to the texture and shader record and texture bitmap, you can set the properties using the other Texture functions.

Cheers,

[Petri]

It is possible, but...there are some things I haven't figured out yet. The main one is how to do it silently, ie., without dialogs showing for each image.

This has been my conclusion from perusing the texture procedures. I'm not sure which is worse: sit and wait for the next dialog to come or do the whole thing one by one.

Maybe I have to forget this - it SHOULD be possible!

[Petri]

Further investigations show that textures are not exported in VectorScript exports. Well, perhaps I can at least get named texture "prototypes" created, so that only the image import needs to be done manually. Somewhat disappointing.

[Petri]

Even further investigations show that nothing related to textures is exported, not even the texture used in objects.

This is getting very annoying! VectorScript files are a good way to merge documents, but Essential Information is Lost in Translation.

Edited November 21, 2006 by Petri

[Petri]

So, no-one else but Rick is willing to share knowledge about creating textures with VectorScript? Here's where I am now: the 3000+ colours in a series of text files:

code, R, G, B

and would need simple, plain colour textures created - I just can't figure out how to do it. Rick's sample code sort of, almost, makes sense, but the feeble attempts I've made on that basis have lead absolutely nowhere.

[Rick Francken]

Petri,

When you exported a vectorscript of your plain color texture, did you see the record format "NNAPlain Color"? The trick is to attach this record to your texture and set its color values. Take a look at the script below...

{********** Script: MakePlainColorTexture ***********}

procedure ScriptMain;

const

COLOR_FAMILY = 1;

PLAIN_COLOR_PROTOTYPE = 6;

var

hTexture, hShader: handle;

rValue, gValue, bValue: string;

begin

{make sure there is a Plain Color record present}

if GetObject('NNAPlain Color')=nil then

begin

NewField('NNAPlain Color','Family','1',1,0);

NewField('NNAPlain Color','Prototype','6',1,0);

NewField('NNAPlain Color','Version','1',1,0);

NewField('NNAPlain Color','Color','255',1,0);

NewField('NNAPlain Color','Color G','255',1,0);

NewField('NNAPlain Color','Color B','255',1,0);

SetObjectVariableBoolean(GetObject('NNAPlain Color'),900,FALSE);

end;

{create and name the texture}

hTexture:= CreateTexture;

SetName(hTexture,(StrDialog('Texture name?', 'fred')));

hShader:= CreateShaderRecord(hTexture, COLOR_FAMILY, PLAIN_COLOR_PROTOTYPE);

{set color values in the Plain Color record}

SetRecord(hTexture, 'NNAPlain Color');

rValue:= StrDialog('Red Value <0-255>','255');

gValue:= StrDialog('Green Value <0-255>','255');

bValue:= StrDialog('Blue Value <0-255>','255');

SetRField(hTexture, 'NNAPlain Color', 'Color', rValue);

SetRField(hTexture, 'NNAPlain Color', 'Color G', gValue);

SetRField(hTexture, 'NNAPlain Color', 'Color B', bValue);

end;

run(ScriptMain);

{********** Script: MakePlainColorTexture ***********}

Note that there is no error-checking built into this quick-and-dirty script. But you should be able to hook up the mechanism to process the color values you read in from your file. You just need to implement a Code -> Texture Name function, and RGB color conversion function if your R, G, and B values are not 8-bit (0 - 255) values.

I haven't tried with the other shader types, but I have a hunch that each shader prototype has its own record format that you would use.

Hope this helps you,

[Petri]

Thanks again, Rick!

Ever since the textures came to VS, I've occasionally tried to understand them, but obviously there's something wrong with me. I have indeed seen the record format, but...

It may just be that when you really get frustrated, you no longer think clearly. Well, don't know about YOU of course, but it happens to me: the Donald Duck Syndrome, as I like to call it.

[Rick Francken]

Petri, glad you could use it.

The Rendering API is a tough one....took me a lot of hours and failed attempts to figure out how to work with textures. And still more to learn yet. But if you can write scripts that generate other scripts for complex polyline creation, you shouldn't have a problem.

Good luck,

[Petri]

Rick, it works like a dream! I took the liberty of making some changes to the peripheral parts and the working version looks like this:

PROCEDURE CreateTexturesFromData; 
{ clever bits by & ? Rick Francken 2007, file input by Petri Sakkinen } 

CONST
COLOR_FAMILY = 1;
PLAIN_COLOR_PROTOTYPE = 6;

VAR
dataFile, textureName, rValue, gValue, bValue: STRING;
hTexture, hShader: HANDLE;

PROCEDURE CreateRecordFormat;
BEGIN
NEWFIELD('NNAPlain Color','Family','1',1,0);
NEWFIELD('NNAPlain Color','Prototype','6',1,0);
NEWFIELD('NNAPlain Color','Version','1',1,0);
NEWFIELD('NNAPlain Color','Color','255',1,0);
NEWFIELD('NNAPlain Color','Color G','255',1,0);
NEWFIELD('NNAPlain Color','Color B','255',1,0);
SETOBJECTVARIABLEBOOLEAN(GETOBJECT('NNAPlain Color'),900,FALSE);
END; 

PROCEDURE CreateTheTexture;
BEGIN
hTexture := CREATETEXTURE;
SETNAME(hTexture, textureName);
hShader := CREATESHADERRECORD(hTexture, COLOR_FAMILY, PLAIN_COLOR_PROTOTYPE);
END; 

PROCEDURE SetRecordValues;
BEGIN
SETRECORD(hTexture, 'NNAPlain Color');
SETRFIELD(hTexture, 'NNAPlain Color', 'Color', rValue);
SETRFIELD(hTexture, 'NNAPlain Color', 'Color G', gValue);
SETRFIELD(hTexture, 'NNAPlain Color', 'Color B', bValue);
END; 

BEGIN { main } 
GETFILE(datafile);
IF NOT DIDCANCEL THEN BEGIN 
	{make sure there is a Plain Color record present}
	IF GETOBJECT('NNAPlain Color') = NIL THEN CreateRecordFormat;
	WHILE NOT EOF(dataFile) DO BEGIN 
		READLN(textureName, rValue, gValue, bValue); 
		{create and name the texture}
		CreateTheTexture;
		SetRecordValues;
	END;
	CLOSE(dataFile);
END;
END;

RUN(CreateTexturesFromData);

It is kinda fun to have the resource browser open in Thumbnails -mode and watch textures appear like magic! Thanks, Rick!

[Rick Francken]

You're welcome. Kind of fun automating a task like that, isn't it? I know I get a kick out of writing software that enables someone to do 100 hours of repetitive work in 5 minutes.

I do like the way you structured the script. It is very readable, and looks easy to understand six months from now.

Cheers,

[Petri]

I do like the way you structured the script. It is very readable, and looks easy to understand six months from now.

Umm... thanks. Yes, I try to pay attention to the structure, variable names, procedure names, capitalization etc, because I'm totally hopeless in documenting or remarking my programs. Also I really like to be able to copy and paste bits & pieces with as few adjustments as possible, be that within one large script or between scripts.

I try (in vain) to maintain a script library in a FileMaker Pro database and standardization helps also in finding the Missing Bit in that.

Just FYI: the said database is also a depository of essential, but seldom needed, generic utilities. These I very often run directly from FMP via an AppleEvent (doScript).

Parts of your kind contribution will not only go into this database: I have another FMP database, which creates classes & their attributes and gradients directly into the current VW document, based on RGB values. Now I can also start to do "paint" textures! The (potential) value here is that I can store an unlimited number of "paint samples" (in numeric format) in a single, extremely fast, "container" and get the "paints" in use in an instance. At present, I have data from Dulux Australia and Tikkurila Paints (Finland & parts of EU) in the system - some 7000 paints. But I digress once again!

[Petri]

So, these textures are created quite nicely, are in the Resource Browser, can be edited - but do not always get rendered with OpenGL. Yes, OGL is to use textures and some behave properly. Others can occasionally START to behave themselves after various, undocumented and unrepeatable, operations. These sometimes, inconsistently, include copying a textured object into a new file.

Everything is always hunky dory in RenderWorks...

Very strange.

[Rick Francken]

Petri,

I did notice two other record formats present when a texture is created, "NNAPreview Object Options" and "NNAShadow Options". It could be that OpenGL relies on these to render correctly, and using the default values of the record format causes the behavior you see. I don't know if this is the case, but you might try testing different value in these records to see what effect they have on OpenGL rendering. (Oh, the joys of meticulous trial and error testing...<g> )

[Petri]

Brute force this time...

Took an NNA texture in each of the 20 files I created, used that to render once in OGL. Then saved, closed, opened, deleted the said texture and all was OK. If the texture was deleted without saving & closing, the odd behaviour resumed.

This suggests that your theory could be correct. Or does it?