HOW TO IMPROVE LIGHTWAVE: SDK and plug-in development


Ok in order to clear the air, I have decided to post a series of threads
where ideas on how to improve Lightwave can be posted in an organized fashion.
The idea is to provide an one stop place where developers (from Newtek, or independent)can come in and get ideas.

This thread along with its sister threads:

[b][b]HOW TO IMPROVE LIGHTWAVE: Character Animation
HOW TO IMPROVE LIGHTWAVE: SDK and plug-in development
HOW TO IMPROVE LIGHTWAVE: Interoperability with other apps


…will be used to provide input on ho to move Lightwave back into the forefront of CG graphics.

But in order to keep things positive (glass half full), and make it something
worth while, there are some rules for this thread:

Please dont provide rants, just provide your ideas.
No bashing Lightwave or any other app. I mean it.
If new research is pointed out, please provide links to it.
Show us real life examples on how your idea would help you.
Please along with your comment, provide suggestions of how to
implement the concept or idea on the workflow. Workflow is one of the
things that make Lightwave what it is.
The can do attitude is what made this community once great, cynicism is
killing it. Someone once told me “Optimism is an act of defiance”.


A GUI, and setup kind of like Flash and its behavior Library stuff


I would like to see everything that’s accessible within the interface accessible through the SDK.


SDK should be made very opened, and most important : well documented.

I’d like to say this : Lw needs also to be well and extensively documented into all of its features, tools and if possible probs too.
Being said that, i really hope for SDK to be opened, API too, and fully support Fprime for all rendering things in Lw. But not only FPrime.
opening SDK is really important for future better plugs that Lw could make a good use of. :slight_smile:


With the SDK open, I would want to implement my idea of Relax UV, Subdivide UV, and even create custom tools such as crowd control and allow me to further modify the animation pipeline myself…


And with the SDK, I can create support of Micropoly Displacement, even plugins for custom skeleton shapes, other than the skelegon shape you get when you create the bones in modeler…


I think the subdivision method in LW is catmull clark. If that’s the case, build your own 3D viewer with LWO file import and sub div the polygons using catmull clark algorithm. Then apply the UV coords based on the subdiv model. Basically create the same effect as if the user froze the subpatch into true polygons and apply UV coords to each new polygon.


You are on the right track, but our only roadblock is that SDS distortion…(damn distortion) By my idea of Subdivide UV, I can add more polygons to the UV Map, without have to re-edit the map altogether…


yes, Lightwave’s SDS is Catmull Clark


My understanding is that lightwave does not have subdivision surfaces, it has subpatches which do not support n-gons. XSI uses Catmull Clark and Doo Sabin. Other applications use Catmull Clark or Catmull Clark compliant subdivision surfaces.


you’re quite right. in fact Lw can’t subpatch n gons , but allows u to work only with quads and tris. they were once called metanurbs.

despite quad and tris being good for organic modelling, where u get best result in deformation with quads only meshes, ngons are so useful for technical and design modelling and allow u to use way less geometry with he same result.


Not to be a spoil sport but haven’t the last 5 posts or so (including this one) broken this rule?


I see no problems with the last 5 messages.


For me, I would like full fxn exposure to all interface and tool features. That pretty much means the ability to work with anything inside LW. I would also like to see it the ability to extend into those fxn’s in such a way that true SSS, other SDS, volumetrics, ect could be viewed inside the native LW rendering system. That would require alittle (OK alot more) work then just fxn exposure but it does give us more power with a simpler workflow then having to have seperate noon-LW windows open.
And of course better doc’s.


Allow 3rd party renderers eg VRAY and MR to be plugged in.


Here the other day i was modelling a tree, mostly to test out the technique. Then, i was done, and had a tree without leaves. I thought that it must exist a plugin for this, i cant sit here all year copying and placing a leaf i modelled. I found several plugins, but they all cost money :cry: . How do I even know i’m going to get what i’m paying for here, (a bit sceptical). So my request to Newtek is to integrate more plugins in to the program itself, which is useable. (ex. Realflow, Treedruid, etc. etc.)
My argument for this is that maya has all these good feautures integrated, and I don’t think that LW, which is way better after my opinion, should be without this.

I use LW on a hobby level, and sometimes i’m like :banghead: , because i can’t find what i’m looking for on the internet, because it doesn’t exist!
What i’m talking about, is (as mentioned) free plugins, useable textures, and easy ways of doing things without paying for it!
Over to the textures: It doesn’t exist an usable place to find free textures on the web. When i don’t have enought time to make my own textures, i usually want to pick some from the web to save time, but they just ain’t good. Some paysites are very good, but who wants to pay for a single texture!!! Therefore, my second request is to add more useable textures (mostly procedurals), to help us 3d-modelers out here save some time.

Lightwave is expensive enough, i don’t want to buy additional software for a single/ a few operations. I don’t trust paysites, so either bring them into the closest store in Norway, or make it free!

Sorry my crappy english, but i’m from a foreign country.

And at last: The presets are not too pro, please make them better…


I posted this in the character animation section on accident:

I had an idea a while back for a modeler plugin in layout. How it would work is that you could ad a special “Polyobject” to your scene. Then, in the properties you could add a modeler plugin to the deformation plugins list. Once you edit this plugin, you enter “Modeling” mode where all of lightwave’s modeler tools are available. The timeline and all other tools are still available but now you can edit the object at the point, edge or poly level and all properties are animatable. You could even make it so that the plugin attempts to emulate modelers programing environment which would allow you to port all of the existing modeler tools straight into layout. You could also add as many Modeling plugins as you need in order to create layered stack operations. Basically, it would work similar to the “Edit Poly” modifier in Max. This would probably require NewTek to make it’s deformation plugin interface more like the modifier stack in Max where each plugin modifies the mesh data coming from the previous plugin.

The main thing I love about this is that it allows you to keep modeling operations contained with in compact objects of data. you could even separate out the different modeling operations like “Create”, Modify, multiply map, and so on into separate plugins so you can keep things better optimized (as opposed to having multiple instances of tools you are using.

Ultimately, what would be even cooler is to replace the deformations plugin list with a button that opens a window and allows you to view a non-liner flow of nodes that could be linked, manipulated and grouped together like in Shake or Houdini.

Actually I think it’s almost possible to do this right now but the main issue is that LightWave doesn’t allow 3rd party plugins to add or remove point data.


This thread so far, has not actually had anything to do with the SDK…
And as i see it as been a complete waste of space…

People should distingqish between features and plugins they would like to see,
included in Lightwave. And errors, omissions, bugs and enhancements to the Lightwave SDK.

And really as it’s a discussion for programmers, scripters and developers, and ones that
know the architecture and know of it’s development issues and struggles it faces to remain
workable…I won’t voice my opinion on this, as there’s much to talk about on this subject…

But, just try to remember if you don’t program in C/++ or aren’t aware of the SDK,
try to keep the “i want this feature” to another thread. As they are very seperate issues.


Just to add some OT issues:
[li]Light Plugin Class - Allow for third party lights
[/li][li]Procedural Images Class - Allow for procedurals to create 2D images to be used like any other image, but with “unlimited” resolution
[/li][li]Separate GUI and Code - Allow the GUI to be defined in, say, and XML file while the logic stays in the code. This would allow users to modify the GUI layout and make development a bit easier
[/li][li]An official C++ wrapper - That helps developers circumvent pitfalls and shortens development time
[/li][li]Since we have new AA types, separate the AA controls and make them a plugin too.
[/li][li]Expose more internals to build upon - Example: How can third parties evaluate the new SDS UVs? They can’t. Basically reduce the amount of reverse engineering needed in many cases.
[/li][li]Make the GUI library available from outiside LW - for example for cross platform helper apps
[/li][li]Allow arguments from LScript to be passed to Plugins, allow plugins to receive commands. - This would make scriptable plugins possible
[/li][li]LScript - for every Get… there should be a Set… and vice versa. Currently some things can only be read or written but not both (Example: Windows positons and open/close states, which makes it a pain to write a window layout manager without hacking the configs…)
[/li][li]Make commands available within LWSN - so that plugins could have more control over renders while lwsn is running, this opens up some nice possibilites
[/li][li]Merge Expressions and LScript
[/li][li]Extend XPanels - the general idea is great but needs to be more flexible. Note: I don’t want pixel accurate layouts, but more control types and more options for a dynamic control layout
[/li][li]Separate projections types and the actual mapping in the texture - Makes it easier for example to apply procedural textures to UVs and would be more transparent to plugins. I.e. a Projection type generates UVW coordinates only (either using implicit projection types such as “Spherical” or using UVs stored in the object. The actual mapping would then be done by another plugin only in respect to the UV coordinates.
Enough for a start? :wink:


Yes, these are much, much better examples…