Is way to render LWCAD Dimensions in LightWave?

intssed

Ints
Hello!

Is way to render LWCAD Dimensions, placed in LightWave Modeler?

Thanks!
 
Last edited:

Shloime

Intermediate User
Could someone maybe write a plugin for that? Get the information about the endpoints of the dimension thing, read the numbers and create an object with this info?
I don't know how to write LScript or Python, so maybe someone else?
 

Sensei

TrueArt Support
Is any else experience how to show measurements in rendering?
Layout does not have built-in real-time text rendering feature.
In native LW you need to create text geometry in Modeler.
Therefore I made special plug-in for real-time text rendering.
 

jwiede

Electron wrangler
I believe the text is only part of the problem, there's also figuring out the endpoints and text contents, and those require accessing info from LWCAD. If Viktor set up attributes for them in LW2020 it might ever so slightly be possible (as in, probably not), but definitely no easy way to do so prior to LW2020 unless Viktor exposed some APIs other plugins could somehow dynamically link against to enumerate dimension entries and their info -- again, not impossible, but not likely either.

And just to point it out... That, above, is precisely what folks mean when we talk about plugins not being "first-class citizens" in LWSDK: Unlike third-party access to "LW-native systems and APIs" there's no efficient manner for plugins to expose interfaces other plugins could access. Comrings aren't that either, btw, but explaining why is a huge tl;dr, so ask if you care.
 

Sensei

TrueArt Support
And just to point it out... That, above, is precisely what folks mean when we talk about plugins not being "first-class citizens" in LWSDK: Unlike third-party access to "LW-native systems and APIs" there's no efficient manner for plugins to expose interfaces other plugins could access.
Not true.
1) Plugin developer can make custom global class (similar like LWSDK uses).
2) In LWSDK 2020 NewTek devs added Components
3) store data is weight, vertex maps.
4) store data in animated envelopes.
5) store data in tags. They are per-polygon data.

The problem is that programmers would have to waste their time making them. To do so, they need good reason to do it. If nobody would ever use them they would just waste their time..

We created custom global class for Kray SDK. It was used by Virtual Render to order KRay render specific region of the image at ultra high resolution.

LightWolf and Otoy made similar thing to allow Mike's plugin to work with Octane.
 
Last edited:

jwiede

Electron wrangler
Not true.
1) Plugin developer can make custom global class (similar like LWSDK uses).
2) In LWSDK 2020 NewTek devs added Components
3) store data is weight, vertex maps.
4) store data in animated envelopes.
5) store data in tags. They are per-polygon data.

The problem is that programmers would have to waste their time making them. To do so, they need good reason to do it. If nobody would ever use them they would just waste their time..

We created custom global class for Kray SDK. It was used by Virtual Render to order KRay render specific region of the image at ultra high resolution.

LightWolf and Otoy made similar thing to allow Mike's plugin to work with Octane.
None of what you described represents a mechanism by which LW allows third-party plugins to expose interfaces other plugins can access. Other than that, you're saying basically the same things I said.

Describing specific cases where both sides cooperated to provide a comm interface between their plugins isn't meaningful, the approaches in those cases were too complex/expensive to be at all scalable, and too involved per party to work with 1:many scenarios (as opposed to the 1:1 scenario where they were used). Just the fact that "both ends of the pipe" had to be directly involved and contribute effort makes it a non-starter as a general plugin API exchange system.

LW "Components"... ROFLMAO! There are a zillion lightweight, easy-to-integrate REDIS interface/binding-compliant in-memory key-value implementations out there, LW devs writing their own poorly-featured/-performant equivalent was completely POINTLESS. What's next, they going to implement their own database and query language/engine for LW? Or maybe their own shader language and toolchain? LW devs wasting time/effort/money reimplementing a crappy REDIS clone was probably the final straw -- if not, it should have been.

(edit) And before someone asks -- I know they rolled the interfaces themselves, because they made the same mistakes they made in other recent APIs, failing to consider synchronization needs, etc. and generally produced a impractical implementation because of what they omitted (they reliably omit certain concerns in APIs/SDKs).
 
Last edited:
Top Bottom