[Closed] Another new feature in 2010: Scripted texture maps

Glad to see they finally fixed that.

-Eric

oh I just setPixels() to a highres bitmap’s buffer to create my own maps

I’m not aware of the ability to script texture maps… how does that work? (already tried to look it up in the maxscript reference, and didn’t see anything)

Information is found in “Scripted TextureMap Plug-ins” and “How To… Create a Dalmatian TextureMap Plug-in”. Like all scripted plugins it allows you to extend an existing Max texturemap and replace the UI. Prior to 2010 mental ray wouldn’t render scripted maps, and would generate an error.

My scripted Solid Color Map that found the issue during beta testing 2010:

plugin textureMap Solid_Color
name:“Solid Color”
classID:#(0x373cef4d, 0x716b0336)
extends:RGB_Multiply
replaceUI:true

(
parameters main rollout:params
(
scColor type:#color default:(color 255 255 255) ui:color1
on scColor set val do delegate.color1 = val
)
rollout params “Solid Color Map Parameters”
(
colorpicker color1 “Color” align:#center fieldwidth:48
)
)
-Eric

Ah, gotcha. Thanks.

Holy moly, what i just saw here…
Talk about dropping one-liner bombshells…

Thanks, Richard

Atm, i tried extending a bitmapTexture class, and save the bitmap buffer to a temp file on disk, which then gets assigned to the bitmaptexture.bitmap .

Is there a better way to pipe the bitmap buffer into the mateditor, without saving it out first?
Not that it’s bad, at all, as the rendertimes would be pretty fast, even with large textures (at the expense of the maxscript time taken to generate it, ofc), but i wonder if i’m doing it right…

nah – it seems to impose the restriction that whatever is in the buffer has a file associated with it… even if modifying the buffer doesn’t modify the file on disk.

Eh, for once i didn’t miss something glaringly obvious
Thanks for taking the time, Richard.