Lightwave 3D Plugin v0.3

[holocube]

My memory is weak!
More than 4 point polys works fine. I tried exporting your badpoly object and it worked fine with the latest version. Could you please make sure you're using the latest .p ?

Thanks

[paulcotto]

I think the file paths are possibly incorrect in the mac version. When I push render nothing happens and lightwave complains " unknown command. "Generic_OctaneExportOBJ". Here is my log file.


LogFile created
Render button pressed
Unitsize is 4
Exporting using Johans exporter
Check if written obj is in temp:
/Users/paulcotto/Library/Caches/NewTek/LightWave/1.0\octanemerge.obj
File is not there
Launching Octane
POI: moby
MyCam: Camera
dist: 71.0544
AimposX: -12.8752
AimposY: 18.4044
AimposZ: 10.3217
Writing cam position Camera
camx:28.9832
camy:0.493799
camz:64.8726
-n "/Users/paulcotto/Documents/Content\Anime_Eyerig.lws.ocs" -m Anime_Eyerig.lws.obj -l "/Users/paulcotto/Documents/Content\Anime_Eyerig.lws.obj" -s 0 --cam-pos-x 28.9832 --cam-pos-y 0.493799 --cam-pos-z 64.8726 --cam-target-x -12.8752 --cam-target-y 18.4044 --cam-target-z 10.3217 --cam-aperture 1 --cam-fov 45.2397
Render button pressed
Unitsize is 4
Exporting using Johans exporter
Check if written obj is in temp:
/Users/paulcotto/Library/Caches/NewTek/LightWave/1.0\octanemerge.obj
File is not there
Launching Octane
POI: moby
MyCam: Camera
dist: 71.0544
AimposX: -12.8752
AimposY: 18.4044
AimposZ: 10.3217
Writing cam position Camera
camx:28.9832
camy:0.493799
camz:64.8726
-n "/Users/paulcotto/Desktop/\Anime.ocs" -m Anime.obj -l "/Users/paulcotto/Desktop/\Anime.obj" -s 0 --cam-pos-x 28.9832 --cam-pos-y 0.493799 --cam-pos-z 64.8726 --cam-target-x -12.8752 --cam-target-y 18.4044 --cam-target-z 10.3217 --cam-aperture 1 --cam-fov 45.2397 --cam-focaldepth 5 --film-width 1024 --film-height 512 --daylight-sundir-x -2 --daylight-sundir-y 2 --daylight-sundir-z 2 --cam-motion-pos-x 28.9832 --cam-motion-pos-y 0.493799 --cam-motion-pos-z 64.8726 --cam-motion-target-x -12.8752 --cam-motion-target-y 18.4044 --cam-motion-target-z 10.3217 -g 0
Render button pressed
Unitsize is 4
Exporting using Johans exporter
Check if written obj is in temp:
/Users/paulcotto/Library/Caches/NewTek/LightWave/1.0\octanemerge.obj
File is not there
Launching Octane
POI: moby
MyCam: Camera
dist: 71.0544
AimposX: -12.8752
AimposY: 18.4044
AimposZ: 10.3217
Writing cam position Camera
camx:28.9832
camy:0.493799
camz:64.8726
-n "/Users/paulcotto/Desktop/\Anime.ocs" -m Anime.obj -l "/Users/paulcotto/Desktop/\Anime.obj" -s 0 --cam-pos-x 28.9832 --cam-pos-y 0.493799 --cam-pos-z 64.8726 --cam-target-x -12.8752 --cam-target-y 18.4044 --cam-target-z 10.3217 --cam-aperture 1 --cam-fov 45.2397 --cam-focaldepth 5 --film-width 1024 --film-height 512 --daylight-sundir-x -2 --daylight-sundir-y 2 --daylight-sundir-z 2 --cam-motion-pos-x 28.9832 --cam-motion-pos-y 0.493799 --cam-motion-pos-z 64.8726 --cam-motion-target-x -12.8752 --cam-motion-target-y 18.4044 --cam-motion-target-z 10.3217 -g 0

[holocube]

My octane obj writer is for windows only, you have to select using the lightwave's own

[3dl]

Hi Holocube,
Since I updated to 3.6 my version of LWCAD, your plugin doesn't export properly geometries....Any chance of having this issue fixed?

[holocube]

Um that sounds very strange. Could you explain a bit more what goes wrong?

[Numerika]

Thanks for the exporter holocube!!
Very appreciated.
Just one thing.. can you make the exporting process faster?
The export process uses only one cpu core (but if I remember correctly this is a NT issue), and sometimes it's very frustrating having the export time higher than rendering time

[face]

Sometimes it isn´t practicable to use multithreading. At least with the Softimage plugin.
At first, you must read 5 things.
First vertices, second normals, third sometimes texture coordinates, fourth faces(which polygon use which vertex-, normal-, texture-, and fiveth material-indices).
For that, you should have a geometry accessor and you should have a referenz for each mesh.
Possible is, that you can use 4 threads to read the mesh data. One for vertices, one for nomals, one for texture if present and one for the indices...

With 4 threads, you must call the accessor 4 times. That cost time.
You must store the geometry data from each thread, because the order of writing the file is imporatant, that cost memory.
You must wait if each thread is finished, because the order of writing, cost time.
All that and the fact that 4 threads aren´t 4times faster, because the thread handling, gives me the not needed argument.
And there are still other things. For example that the indices thread will use 2/4 - 3/4 of all the time.
Or i must read data double for the indices to become the vertex and normal count.
And the greatest argument is, that not the access of the data cost the most time, rather the conversation from the data to a writable string.
If you can solve that, you can half the export time. They should be faster then the import time in Octane...

You see, sometimes it isn´t practicable to convert a serial workflow, read data/write data, to a parallel one, read data/store date/wait for others/write data...

face

[Numerika]

Wow, thanks for the explanation face!
I really wish that octane LW exporter will continue to improve!

[opm]

For me, only export geometry ok the fast exporter. The normal exporter is very slow an always have geometry errors in my case.
Another problem is sometimes export textures and maps and sometimes no (in different projects).
This is a question I want to ask here

[face]

For a triangulated cube you have 8 vertices but 24 normals. The ratio is also 1:3.
Maybe that is the time difference...

face