PDA

View Full Version : Source code for LW3dG native plugins



jeric_synergy
08-27-2014, 05:04 PM
PERHAPS this has already been done, but if it hasn't:

How helpful/useful would it be for LW plugin developers to have the source code for NATIVE LW3dG plugins and scripts, i.e. the plugins that come with Lightwave?


Are they already in the various dox made available for plugin developers and advanced scripters?

ernpchan
08-27-2014, 05:29 PM
Well I guess with that idea then all plug-in developers sharing their code would be great but that's not realistic. The code is intellectual property.

Jarno
08-27-2014, 05:40 PM
There are a bunch of source samples in the LWSDK, many of them derived from shipped plugins.

---JvdL---

jeric_synergy
08-27-2014, 05:54 PM
Well I guess with that idea then all plug-in developers sharing their code would be great but that's not realistic. The code is intellectual property.
Note I said "LW3dG native". Certainly I'd never expect 3rd party devs to share their code.

BUT, since it is in LW3dG's best interest to develop a healthy ecosystem of plugins, it is in their best interest to chum the waters by giving developers as many examples as possible.

Really, I'm disappointed in you ernpchan.

jwiede
08-27-2014, 06:06 PM
I do think some more complex examples could be helpful, but only if the code is well-commented and comprehensible. Publicizing poorly-commented, dense, obfuscated production code would offer very little benefit.

All that in mind, a couple examples which show how some of the recent "New Tools" were implemented could be highly valuable, as could practical examples showing how plugins should expose APIs from their code for access from Python code. Most of the existing plugin examples use fairly ancient GUI/UX design and interaction, which sets a poor example for plugin developers. Likewise, the lack of examples on efficient intercommunication and scripting _of_ third-party plugins does nothing to encourage change from the existing sea of nigh-all externally inaccessible third-party plugins.

ernpchan
08-27-2014, 06:13 PM
Really, I'm disappointed in you ernpchan.

Well I'm playing devil's advocate to the extreme. Hypervoxels for that matter is a plugin. If the LW3DG wants to share that code then by all means they're welcome too. I'm just saying that opening up a lot of the code and how some of the unique stuff is done to 3rd parties could be dangerous. You run the risk of that code being shared with a competitor.

But I do see where you're going with your initial idea. Getting access to more does help 3rd parties develop on top of or completely replace existing tools because they can see a problem from a different pov. I know I've benefited from the devs opening up more through the sdk.

jwiede
08-27-2014, 07:33 PM
I'm just saying that opening up a lot of the code and how some of the unique stuff is done to 3rd parties could be dangerous. You run the risk of that code being shared with a competitor.

In contrast to hardware, it is astoundingly difficult to conceal how software operates. The second an executable is distributed to customers, should an engineer from a competing app want to know how the app accomplishes an operation, they can take a disassembler and/or debugger to the package and find out precisely how it works. With modern commenting disassemblers, identifying between different algorithms and exploring optimization techniques can all be quickly done without ever seeing the original source code. In fact, in terms of reverse engineering, having the original source is frequently more of an impediment than an aid, as it leaves any viewer "contaminated" such that they must not be allowed to participate in subsequent "re-implementation" elsewhere.

The vast majority of 3D technology implementations in today's packages are heavily derived from papers and information which have been publicly-available for many years (SIGGRAPH being one of a fairly small population of venues where such papers are presented and discussed), combined with varying amounts of optimization and tuning. Because of that, there is very little basis for believing that many, let alone most, other companies' engineers do not already know precisely how Lightwave does any given operation, despite having implemented similar functionality in their package (using similar area expertise).

As the algorithms employed are commonly well-understood, and the optimizations employed are easily extracted from the executable disassembly, the dominant commercial concern is typically how quickly and efficiently technologies can be integrated into the existing product's infrastructure. Understanding how other companies handled the integration into their (divergent) infrastructures is not particularly useful in addressing that concern, due to the detail differences between 3D packages' infrastructures.

jeric_synergy
08-27-2014, 08:18 PM
Of course, everything is up to the discretion of LW3dG. But certainly good examples of use of new infrastructure can only rebound to their favor.

For instance, the newish modeler tools with the built-in onscreen 'auto-documentation' leaps to mind.

ernpchan
08-27-2014, 08:28 PM
Totally agree.

If their examples were thoroughly commented that would help. But commenting code is laborious because as a programmer you just assume other programmers reading your code understand the environment.

When I need help I like to reference the line from Galaxy Quest.

Sarris: He doesn't understand. Explain as you would a child.