I decided to create a new thread here about this, so we don’t clutter the notification thread too much, or place too much off-topic information there.
So what is the PDK?
Well, I’m not the best person to answer that, but I can start providing part of the answer that I know…
PDK is the “Plug-in Development Kit”. It allows (will allow) someone wth some programming knowledge to actually make a plug-in for WM. A plug-in could be a device, for instance.
So what is the benefit of a device made as a plug-in over a macro?
A macro will use devices and functionality available in WM. If new stuff needs to be made, the only way to make it is with a plug-in. Imagine you want to do some sort of wind erosion, where you specify a direction for the erosion to go. There have been some attempts at doing that in macros, but they were not very sucessful, or limited…
with a plug-in, you have access to more information and operations that allow you to manually decide what to do to individual height pixels.
As for other application to plug-in making I can’t say much for sure, as nothing has really been defined anywhere yet. When the PDK is ready, everything we need to know should be available.
indeed… I wanted to reply here, since this is the more appropriate thread:
Sounds good.
Can you explain what the PDK can do?
Does it allow a non coder to develop Plug-Ins by using a grafical ui?
That’s actually what Macros allow you to do. Of course, you can’t do anything that can’t be done by some combination of existing devices, but within that limitation you can do some impressive things.
The PDK is designed to allow programmers to create their own new devices in World Machine. Since WM was written in C++, plugins need to be as well – although a “function wrapper” could certainly be written that would allow plugins to be written in any language.
I sure wish I knew enough about coding to generate a 16 bit BMP aka G16 output option…
The level editor I use for games uses this format. I can get very close by saving as an 8 bit BMP then discarding the color information in PS and using a program called g16 to import and then save as the proper type, but there is some loss in the finer erosion details.
I solved this by choosing “.r16” as the output then changing the file extension in Windows after the export to “.raw”. With no other changes I was able to now open this fine in photoshop. Sometimes you may get a dialog when opening. Off the top of my head choose Channels:1, Depth:16, and Byte Order: IBM PC. That will allow the proper viewing and usage as a full 16 bit file in Photoshop. If the file seems garbbled there may be a setting I’m missing in the last sentence but keep adjusting the settings and you’ll get it eventually.
Jimbo Younkin
World Builder
Cheyenne Mountain Entertainment
“Stargate Worlds”
Seing as you mentioned something of a wrapper above and i just assume you mean it for managed languages, i’d like to ask if anything in that direction is already available?
I realize that you’d probably have to go full CLI to do this so no biggie if at this point in time that isn’t an option, what with all the time required for that.
This sounds great. Awhile back on the forum I noticed that someone had made some kind of ‘send to Mari’ plugin for WM, but it wasn’t available for download.
I’d love to try my hand at something similar sometime, basically make a plugin that sends to Mari the locations of outputted textures/masks from WM, plus a mesh, and then use that information to create a new Mari channel which has all the textures inside of it, ready for additional painting.
My only programming experience is in Python, where I’ve made similar bridge type plugins to send stuff from Mari to Maya, etc. I’ve no idea how I’d go working in C++.
