View Full Version : lightwave API

07-23-2004, 02:28 PM
just asking why newtek is sticking with closing on the API, what is the worst case if they open it, beside the huge advantages that will occur to lightwave if they open the API.
if it's a mistake to open the API, is this mean that all other application on the market (maya, max, xsi, cinema4d....) r dumb, and wrong cause they opened their API.
i can't understand the case really, and plz don't said that they don't open it, cause they fear from copying the code or similar things, cause in my opinion, in the current state, i doubt that any other application want to copy anything from newtek, especially the slow and outdated renderer.
if it's about modeller, look to the new product modo from luxology, it will b a great modeller, and with no doubt all users will like it, cause they will feel as it's the waited version of lightwave modeller, with all these things modo will b open API, so what's the cause to not open it for newtek???
and plz i don't want that anybody take this as a negative of newtek or lightwave, cause i'm lightwave user and lightwave lover since 6 years, i teach and work as professional with lightwave, but i like to know too, what's going on?in order to know what is the future of this great package.

07-23-2004, 03:16 PM
I believe that if they COULD open it they would.
They probably just literally can not open it yet - there's no capability for it.

07-23-2004, 03:33 PM

07-23-2004, 10:21 PM

As I understand it, it's not a political or philisophical reason that keeps the API from being as open as Maya or other apps, it's just the nature of the architecture, which they are addressing. I'm not quite sure you really understand your own question.


07-24-2004, 07:19 AM
making an accessable api doesnt have anything to do with opening your source code and risking it getting stolen. its simply a matter of preparing the architecture of the software for the sdk, and let developers have access to the function headers.

currently lightwave lacks in the sense that the current architecture doesnt prove the needed access to lightwave, and hence limits the sdk and the developers.

on a positive note, its an area that have continously been reported as being worked on since the release of 8.


07-24-2004, 10:32 AM
What I wonder is ... Why does it take so long to get things into the sdk? If you look at the new poly type plugin (so you can do your own sub d surfaces etc) the example code with the sdk is source that was written several years ago. So abviously this plugin would have worked several years ago too ... so why wasn't this feature in the sdk?

I'd also like to see more code given away from Newtek ... would it really be that bad if they included the source for all of their basic tools? :confused:

07-24-2004, 12:25 PM
Originally posted by Karmacop
What I wonder is ... Why does it take so long to get things into the sdk?

I'm going to give you a visual explanation to tell you why.

Imagine you work for a phone/networking(=NewTek) company of some sort as a "cable guy"(=Lightwave coder). Most of the time you see cables(=program code) that is constructed nicely and form an easy-to-use-and-modify kind of a whole, just like cables in this picture:

In order to add some new cables (=code to connect the functionality of the program thus give the plugin coders ability to use some of the funcions thru API) is very easy in the above situation and if needed, a whole bigger module can be easily added. The picture above may represent just about any program there is, it's irrelevant at this point.

The problem is that LW at its current state looks a lot like this:

I hope you get what I mean. I've spoken.

07-24-2004, 12:30 PM
ROFL That register picture looks like the back of my computer :D

07-24-2004, 12:55 PM
It's not about what the code looks like, my point is the example code was written years before it was documented. This meant that the hooks were already in place for this new type of plugin (as Newtek's plugin worked) but it has only recently been added to the SDK.

07-24-2004, 01:06 PM
Originally posted by Karmacop
It's not about what the code looks like, my point is the example code was written years before it was documented. This meant that the hooks were already in place for this new type of plugin (as Newtek's plugin worked) but it has only recently been added to the SDK.

The methaphorical message above is relevant also to what you said: Even that the hooks are there, they're not possibly even easy to find because of the patch-on a patch-on a patch-on a patch -kinda state LW seems to be right now (I'm not talking about LW8 actually, but what was left for NewTek to deal with). I'm sure there's a lot of cleaning to do in LW and that's why I'm one of those who'd like to see LW completely rewritten soon.

07-24-2004, 11:18 PM
Ok .. well .. I still don't get it :p

I think what Newtek are currently doing is better than rewritting Lightwave straight out. At the moment they're slowly rewritting sections, so that we still get updates in a timely manner. I would hate to wait 6 years ot whatever like the softimage people did for XSI :(

07-26-2004, 05:15 AM
Opening up certain features would indeed make it easier for
others to copy Lightwave unique features like LW nurbs.

For which NT and it's initial developers have guarded for dear life..
(Enter dramatic music)

For example if LW someone wanted to make an OGL preview
window that previews metanurbs, they would have to just use an
approximation of the two commonly known methods of nurbs,
(which other programs are based on, like convex hull)
but at times it would not represent LW's implementation.
as LW uses the colonel's secret herbs and spices to do it's magic.

LW's architecture is unique, and really it must be a game of trading features for accessability and 3rd party development....

I can't see a problem with Hypervoxels though, as i understand
it Maya has a much faster version anyway....

07-26-2004, 07:00 AM
newtek wouldnt have to show their nurbs code for third party developers to make use of them.

simply put, what would basicly be needed, is for the SDK to have access to the nurbs algoritms, but for the developer its a matter of feeding a header into a black box, which then returns a set of data to use for your opengl preview, or whatever you are using it for.

this wont in any way allow others to copy the nurbs code, and same goes for the rest of the source code. trading features and accessability to preserve secrets is not needed, and its incorrect to assume so.