Octane Sketchup Exporter Beta s [superseded]

Forums: Octane Sketchup Exporter Beta s [superseded]
SketchUp Integrated Plugin (Integrated Plugin maintained by OTOY)

Octane Sketchup Exporter Beta s [superseded]

Postby TIG » Sat Jul 10, 2010 2:09 pm

TIG Sat Jul 10, 2010 2:09 pm
Here is beta.s
Octane_1022s.zip
(268.05 KiB) Downloaded 402 times


A glitch with Ks specular values in the MTL has be resolved [always=0.0 as SUp can't support this value anyway]

All users should upgrade to this version - feedback please...
Last edited by TIG on Tue Jul 13, 2010 10:25 am, edited 1 time in total.
TIG
User avatar
TIG
Licensed Customer
Licensed Customer
 
Posts: 536
Joined: Wed May 12, 2010 1:25 pm

Re: Octane Sketchup Exporter Beta s

Postby radiance » Mon Jul 12, 2010 9:13 am

radiance Mon Jul 12, 2010 9:13 am
Hi tig,

as in this version: viewtopic.php?f=31&t=2671
i'm still getting the exact same error on startup, which i ignore,
and the scene still comes through with many missing textures and the walls being a glossy with a very low roughness,
nothing is different.

i sent you this file, maybe you can use it as a test file ?
I understand you sent me a 'corrected' file in return, but the fact of the matter is that once we go live with this and we have 100 sketchup users,
you don't want to go receiving they're files and modifying them.

Therefore i think it's important you try to fix the issue so the scene (unmodified) renders fine in octane...
I got this scene from an architect friend and he's got many more which don't work...

Radiance
Win 7 x64 & ubuntu | 2x GTX480 | Quad 2.66GHz | 8GB
User avatar
radiance
 
Posts: 7633
Joined: Wed Oct 21, 2009 2:33 pm

Re: Octane Sketchup Exporter Beta s

Postby TIG » Mon Jul 12, 2010 11:20 am

TIG Mon Jul 12, 2010 11:20 am
T

Excuse me... but... a SKP must be structured properly by its creator in order for it to be rendered correctly in any application.
I cannot make allowances for a SKP like the one you supplied to me - with many errors in it.
You said there was 'missing geometry' - the 'missing window pane' just wasn't there in the original - we can't choose to add it on the off chance that the users has made a mistake - perhaps he didn't want to show that window for some reason!
That SKP also needed 'fixing' and 'purging' before attempting any other operations...
The main issue with that SKP was that there were many faces turned the 'wrong way round', so that the faces' fronts were looking into the building rather than to the outside.
Note how when I fixed the SKP I used Monochrome mode to spot the reversed faces, then simply sampled each face's material, reversed the face and reapplied the texture to its 'front' rather than its 'back'.
Faces are always correctly set in the OBJ/MTL and they do get rendered 'properly'.
The issue isn't with the exporter but with the SKP itself.
The "back" of a face is always rendered by Octane in an "off-white" 'default color'. When the user has incompetently applied a face's color/texture to its back-surface, which he has made to look at the camera by mistake, then that face will not show that color/texture: the front of the face will be colored/textured as the user has determined - but it might well also be left in the SKP's 'default-front-material' and/or it might just be looking into the building or into the inside of an object, and therefore it might never get to be seen.
Octane ignores back face materials, quite sensibly, and makes them 'off-white'!
You originally asked for the exporter to include the front face materials only.
It would be possible to add convoluted coding to also export a faces' back-material into the OBJ/MTL - almost doubling the file size and time to export... It would also condone sloppy SKP modeling by users who should know better than to have back faces looking the wrong way... Testing with SUp's own Pro OBJ exporter in 'two-sided-face' mode also produces unexpected results with Octane anyway - It makes coplanar faces with the two materials in the OBJ and MTL, but Octane seems to ignore the 'back-face' and the back material and give the front material to both surfaces of the one face - so that wouldn't address the issue anyway - because the user's mistakenly textured 'back' face looking at the camera will always get ignored and the inside face material used for both surfaces anyway !!! Two-sided-face export is therefore NOT logical.

For the avoidance of doubt/confusion let's consider a simple example...

A SKP user makes a cube with an open top - i.e. a 'box'.
Its faces all look 'outwards'.
In SUp's Monochrome mode the 'outside' of these faces look 'off-white' and the inside faces are in the 'blue' default-material color.
Capture1.PNG

Now the user 'paints' with his desired materials.
The outside [front] faces are colored 'red'.
The inside [back] faces are colored 'green'.
Capture2.PNG

After an export and subsequent render [in Octane] he'll get a 'red' box - but where the inner surfaces are visible they are shown 'off-white' in the render, as 'back' surfaces are not rendered.
Capture3.PNG

Remember that SUp is face modeler - it doesn't model "solids"... but planes with fronts and backs.
If the user really wants a solid box with a 'red' outside and a 'green' inside then it is quite simply done...
He simply gives the box walls with a thickness - just as in the real world [remember that even a sheet of paper has two 'faces', not one 'face'].
Capture4.PNG

Then any materials that are applied to the box's walls front-faces will export properly and then they'll render as a red outside and a blue inside.
Capture5.PNG


We must assume a reasonable level of competency for the SUp users.
There is no way 'we' can double-guess which way round a face is 'meant' to be
[in fact a tool to do this a the 'holy-grail' of scripters - but it's so easy to contrive a form where the inside is the outside and vice versa that is unworkable].
The user must decide how his SKP is structured: there are several tools built into SUp, like Monochrome mode, reverse faces and orient faces, to help him get his model setup correctly before it's given colors/textures etc and then finally exported for rendering.

______________________________________________

T

I am working on this js 'error at startup', which relates to the two sliders' widget import/update.
I hope to have the sliders hard-coded into the next version and thereby avoid this blip.
I have only had one other report of this problem in the feedback - but it certainly needs sorting!

______________________________________________

T

If you were to erase [or rename] the original OCS file and then retry making a render [using my updated SKP and a new OCS] then you should find that the textures come through correctly and the 'specularity' issue is fixed in this latest version
[an error in the earlier MTL writer code set material's specularity [Ks] to 0.3333 [33%], when SUp can't even set/change these values for its materials anyway - so this must always be done inside Octane: now the MTL's Ks=0.0000 always].
Note that Octane will NOT overwrite any the texture, specularity, gloss, transparency etc of any existing materials in the OCS on a 'Relink' - you should know that [!].
BUT in passing [as stated in the tool's Help file] I'll mention here that Octane never seems to read the opacity/transparency of a material - even when its 'd' value is correctly set in the MTL file, either at the first 'Link', and thereafter on any 'Relink'.
I can see that you wouldn't want a 'Relink' to overwrite values that the user might have subsequently adjusted for any 'existing' materials as currently setup in the OCS, but any 'new materials' that appear in the OBJ/MTL are being defaulted to 'solid' too and there 'd' values ignored... surely this can't be the intention - can it ???
TIG
User avatar
TIG
Licensed Customer
Licensed Customer
 
Posts: 536
Joined: Wed May 12, 2010 1:25 pm

Re: Octane Sketchup Exporter Beta s

Postby TIG » Mon Jul 12, 2010 2:23 pm

TIG Mon Jul 12, 2010 2:23 pm
That suanimate plugin DOES indeed make the individual scenes - if you tell it to - then in Octane you set the start/end frames using its first/last scenes and it will make the animation image set as a walk-through or fly-round. However, it will NOT pick up on each scene's layers or hidden geometry etc [these are currently set by the Current View [or Scene] or the actual Scene that you have selected in the Render Settings section of the dialog]. If you elect to use the sun settings in the Octane Render options these will animate too, but not the other settings.

This is the way I was asked to animate scenes in a SKP in Octane. You will appreciate that otherwise with each scene you could have different layers/visibilities on/off affecting available geometry [the way the animator works when animating objects] and therefore you'd need to write an individual OBJ/MTL file set for every scene [the animation exporter currently makes the one OBJ/MTL from the SKP based on the specified Scene's settings, which already only includes objects that are currently set as 'visible'], it then animates the camera, sun etc and then renders it and repeats the process... To make an animation with moving objects created by varying layers etc is akin to setting each scene and rendering it as 'one frame' in turn and saving the render manually...

It would be possible to make the animation renderer export each of the scenes with that scene's hidden-geometry and layers individually set. It would have to change the active_view to the Scene tab [specified from the list of frames to animate], then export the specific scene's geometry/materials etc as an OBJ/MTL specifically for just that one frame, then it'd render that one frame as img00001.png etc and then repeat the process, iterating through the list of frames [scenes] - processing each one individually. This could be very time intensive for larger models as you'd need to export the OBJ/MTL multiple times - the current way is to export just the once, and render multiple frames from that one OBJ/MTL file set with animated camera and sun settings if specified.

If T@Radiance would like this alternative [but quite clunky and much slower] animation frames rendering method it could be done... with some effort...
I suppose it could even be an extra check-box on the dialog "Animate with Visibility" - No= the current method; Yes= the slower multiple OBJ/MTL making method - but I know T@R is very keen on keeping all exporters as similar in appearance and function as possible...
:?
TIG
User avatar
TIG
Licensed Customer
Licensed Customer
 
Posts: 536
Joined: Wed May 12, 2010 1:25 pm

Re: Octane Sketchup Exporter Beta s

Postby nipparnlert » Mon Jul 12, 2010 2:50 pm

nipparnlert Mon Jul 12, 2010 2:50 pm
TIG wrote:T

Excuse me... but... a SKP must be structured properly by its creator in order for it to be rendered correctly in any application.
I cannot make allowances for a SKP like the one you supplied to me - with many errors in it.
You said there was 'missing geometry' - the 'missing window pane' just wasn't there in the original - we can't choose to add it on the off chance that the users has made a mistake - perhaps he didn't want to show that window for some reason!
That SKP also needed 'fixing' and 'purging' before attempting any other operations...
The main issue with that SKP was that there were many faces turned the 'wrong way round', so that the faces' fronts were looking into the building rather than to the outside.
Note how when I fixed the SKP I used Monochrome mode to spot the reversed faces, then simply sampled each face's material, reversed the face and reapplied the texture to its 'front' rather than its 'back'.
Faces are always correctly set in the OBJ/MTL and they do get rendered 'properly'.
The issue isn't with the exporter but with the SKP itself.
The "back" of a face is always rendered by Octane in an "off-white" 'default color'. When the user has incompetently applied a face's color/texture to its back-surface, which he has made to look at the camera by mistake, then that face will not show that color/texture: the front of the face will be colored/textured as the user has determined - but it might well also be left in the SKP's 'default-front-material' and/or it might just be looking into the building or into the inside of an object, and therefore it might never get to be seen.
Octane ignores back face materials, quite sensibly, and makes them 'off-white'!
You originally asked for the exporter to include the front face materials only.
It would be possible to add convoluted coding to also export a faces' back-material into the OBJ/MTL - almost doubling the file size and time to export... It would also condone sloppy SKP modeling by users who should know better than to have back faces looking the wrong way... Testing with SUp's own Pro OBJ exporter in 'two-sided-face' mode also produces unexpected results with Octane anyway - It makes coplanar faces with the two materials in the OBJ and MTL, but Octane seems to ignore the 'back-face' and the back material and give the front material to both surfaces of the one face - so that wouldn't address the issue anyway - because the user's mistakenly textured 'back' face looking at the camera will always get ignored and the inside face material used for both surfaces anyway !!! Two-sided-face export is therefore NOT logical.

For the avoidance of doubt/confusion let's consider a simple example...

A SKP user makes a cube with an open top - i.e. a 'box'.
Its faces all look 'outwards'.
In SUp's Monochrome mode the 'outside' of these faces look 'off-white' and the inside faces are in the 'blue' default-material color.
Capture1.PNG

Now the user 'paints' with his desired materials.
The outside [front] faces are colored 'red'.
The inside [back] faces are colored 'green'.
Capture2.PNG

After an export and subsequent render [in Octane] he'll get a 'red' box - but where the inner surfaces are visible they are shown 'off-white' in the render, as 'back' surfaces are not rendered.
Capture3.PNG

Remember that SUp is face modeler - it doesn't model "solids"... but planes with fronts and backs.
If the user really wants a solid box with a 'red' outside and a 'green' inside then it is quite simply done...
He simply gives the box walls with a thickness - just as in the real world [remember that even a sheet of paper has two 'faces', not one 'face'].
Capture4.PNG

Then any materials that are applied to the box's walls front-faces will export properly and then they'll render as a red outside and a blue inside.
Capture5.PNG


We must assume a reasonable level of competency for the SUp users.
There is no way 'we' can double-guess which way round a face is 'meant' to be
[in fact a tool to do this a the 'holy-grail' of scripters - but it's so easy to contrive a form where the inside is the outside and vice versa that is unworkable].
The user must decide how his SKP is structured: there are several tools built into SUp, like Monochrome mode, reverse faces and orient faces, to help him get his model setup correctly before it's given colors/textures etc and then finally exported for rendering.

______________________________________________

T

I am working on this js 'error at startup', which relates to the two sliders' widget import/update.
I hope to have the sliders hard-coded into the next version and thereby avoid this blip.
I have only had one other report of this problem in the feedback - but it certainly needs sorting!

______________________________________________

T

If you were to erase [or rename] the original OCS file and then retry making a render [using my updated SKP and a new OCS] then you should find that the textures come through correctly and the 'specularity' issue is fixed in this latest version
[an error in the earlier MTL writer code set material's specularity [Ks] to 0.3333 [33%], when SUp can't even set/change these values for its materials anyway - so this must always be done inside Octane: now the MTL's Ks=0.0000 always].
Note that Octane will NOT overwrite any the texture, specularity, gloss, transparency etc of any existing materials in the OCS on a 'Relink' - you should know that [!].
BUT in passing [as stated in the tool's Help file] I'll mention here that Octane never seems to read the opacity/transparency of a material - even when its 'd' value is correctly set in the MTL file, either at the first 'Link', and thereafter on any 'Relink'.
I can see that you wouldn't want a 'Relink' to overwrite values that the user might have subsequently adjusted for any 'existing' materials as currently setup in the OCS, but any 'new materials' that appear in the OBJ/MTL are being defaulted to 'solid' too and there 'd' values ignored... surely this can't be the intention - can it ???


I argee with TIG because i found this problem too but not from sketchup plugin. I export model .skp to .obj. Seem like octane confuse about front material and back material but not for every object. I have to assign same material for both front and back.
new user :
Hardware : win7-x64 / i7-930-2.8 / ASUS P6T / PCI Express x16 Gen2 / DDR3 G.Skill 6GB. / Inno Geforce GTX470 CUDA Cores 448 / CoolerMaster / GX-750
Software : Octanerender pre-Beta 2.42 / Sketchup8 / Nvidia Driver 260.99 / CUDA 3.2.1
User avatar
nipparnlert
Licensed Customer
Licensed Customer
 
Posts: 75
Joined: Fri Jun 18, 2010 3:59 pm
Location: Thailand

Re: Octane Sketchup Exporter Beta s

Postby radiance » Tue Jul 13, 2010 7:53 am

radiance Tue Jul 13, 2010 7:53 am
Hey TIG,

I think the point i'm trying to convey is that we need to be able to have non developers work with the plugin.
My 2 architect friends who use sketchup have not managed to produce a render with the plugin (they keep falling back to to do the final render in sketchup) as textures etc don't make it through.

Roen can send you dozens of scenes, real world scenes they do for customers, and nearly all of them export to octane with 50% of material missing...

I also need to find out why a sketchup plugin exported model pans 10x slower.
this does'nt seem to happen with the other exporters.
could you mail me just the bit of code that does the camera ? eg takes the camera data from sketchup and converts it into the command line arguments ?

Radiance
Win 7 x64 & ubuntu | 2x GTX480 | Quad 2.66GHz | 8GB
User avatar
radiance
 
Posts: 7633
Joined: Wed Oct 21, 2009 2:33 pm

Re: Octane Sketchup Exporter Beta s

Postby TIG » Tue Jul 13, 2010 10:17 am

TIG Tue Jul 13, 2010 10:17 am
T

Roen did have a model where some faces were reversed - he fixed them and it worked.
It is a common pitfall to model 'sloppily' when you are not planning on exporting it to a renderer - because within SUp itself reversed faces with materials applied do not cause problems when rendered internally. However, if you export the SKP to other formats it will go wrong - As I showed in the example images in this thread, having a reversed face visible in the SKP must give a certain result in Octane - you cannot expect to apply the materials to the 'wrong sides' of faces in the SKP and then expect the Octane exporter to somehow magically decide which way round you really intended them to be...

Roen did highlight an unexpected problem a week or so ago - where there were indeed 'missing textures'. This was caused by some materials' texture-names were getting translated into the 'locale' name [Dutch] by Sketchup when queried by the API. but the API texturewriter that exported them would still use the original English name - e.g. 'Red' v. 'Rood'. This meant that although the textures were all exported, they had their English names [e.g. 'Red.jpg'], but the paths in the MTL were made 'wrongly' because they were set from the material's texture-name translated from say 'Red.jpg' to 'Rood.jpg' and so sometimes Octane wasn't finding the texture files it expected.

BUT when this was discovered I quickly fixed it [beta.q+r]. So now in non-English versions the material-name and texture-name in the OBJ/MTL might be a translated version [e.g. 'Red' >> 'Rood'] but the SUp API's texturewriter "non-transaltion" issue has been circumvented, and the texture-files in the xx_Texture folder do have the correct name corresponding to that in the MTL etc [e.g. 'Rood.jpg'] and so they are found. I have had no substantive reports of missing textures since then... If Roen still has some SKPs [without any textured 'back-faces'!] that are still missing some textures, then can he get in touch by email and send me the SKP/OBJ/MTL/Textures-folder zipped up in the same way he has done before, when the 'translation' issue was uncovered...

Note that when you have an 'old' OCS it might have materials already set that look for these 'missing textures' and so are 'blank' - 'Relinking' the OBJ does NOT change this - Octane ignores the OBJ/MTL file's values when a material already exists [it always ignores the MTL's transparency 'd' setting - even for the initial Link, let alone for 'new materials' - why is this exactly ?]. BUT if you make a new OCS you should find that the textures will now get added correctly to that new one on a rerun of the exporter/render...

_________________________________________________________

Also please note that I have now resolved the js 'slider' issue and the beta-t version will be posted shortly - please upgrade to this...
Can you also advise Roen to do the same so that he keeps in step...

_________________________________________________________

The camera command-line parts are written from the SKP's camera values - eye=pos, target=target and up=up - note how fov is different - see below.
The command-lines that are produced are just as you might do 'manually'...
Code: Select all
--cam-pos-x -1.89090096621376 --cam-pos-y 2.04291456204284 --cam-pos-z 1.45892019930385 --cam-target-x 0.127291596394931 --cam-target-y 0.704819315454067 --cam-target-z 0.105858863582895 --cam-up-x 0.0101771938823304 --cam-up-y 0.0222492645941363 --cam-up-z -0.00682311876648562 --cam-fov 52.3015975216335

These are XYZ values taken for simple 3d points [or a 3d vector in the case of the 'up' value] returned by the SUp API for each of these camera properties. X=X, BUT Y is Z, and Z is -Y because the coordinate system in SUp is different to that required by Octane [and also in the usual OBJ format]. The values are adjusted from the 'inch' values in the SKP and made into 'metres' and then a float, and then a string for Octane's use.
Code: Select all
posa=acc.eye.to_a
    pos=[0,0,0]
    pos.x=posa.x.to_m.to_f
    pos.y=posa.z.to_m.to_f      ###
    pos.z=posa.y.to_m.to_f * -1 ###
    targeta=acc.target.to_a
    target=[0,0,0]
    target.x=targeta.x.to_m.to_f
    target.y=targeta.z.to_m.to_f        ###
    target.z=targeta.y.to_m.to_f * -1   ###
    upa=acc.up.to_a
    up=[0,0,0]
    up.x=upa.x.to_m.to_f
    up.y=upa.z.to_m.to_f        ###
    up.z=upa.y.to_m.to_f * -1   ###
    ###
    cline=cline+" --cam-pos-x "+pos.x.to_s
    cline=cline+" --cam-pos-y "+pos.y.to_s
    cline=cline+" --cam-pos-z "+pos.z.to_s
    ###
    cline=cline+" --cam-target-x "+target.x.to_s
    cline=cline+" --cam-target-y "+target.y.to_s
    cline=cline+" --cam-target-z "+target.z.to_s
    ###
    cline=cline+" --cam-up-x "+up.x.to_s
    cline=cline+" --cam-up-y "+up.y.to_s
    cline=cline+" --cam-up-z "+up.z.to_s

The later lines are appending the camera details to the command-line string...

The "fov" in SUp is always returned as vertical [in degrees] - it needs to be converted to "horizontal" for Octane [and several other 3rd party apps], so there has to be some convoluted calculations - see below. Here 'acc' is the 'active_camera', 'fol' is its focal-length, 'fovV' is SUp's vertical 'fov' for the camera, '@width' and '@height' are the current screen/image sizes, note that SUp's 'aspect_ratio' and 'image_width' are not normally set - unless a specific 'camera type' has been selected, probably from another plugin tool - otherwise the screen's width/height ratio is used etc etc...
Code: Select all
    fol=acc.focal_length
    fovV=acc.fov
    [email protected]_f
    [email protected]_f
    if acc.image_width != 0
      wid=acc.image_width
      if acc.aspect_ratio != 0
        aro=acc.aspect_ratio
      else
        aro=wid/hei
      end#if
      hei=wid/aro
    end#if
    h=2*fol*Math::tan(fovV.degrees/2)
    w=h*wid/hei
    fov=(2*Math::atan(w/(2*fol))).radians
    cline=cline+" --cam-fov "+fov.to_s

The last line cline=cline+" --cam-fov "+fov.to_s appends the "--cam-fov " and the horizontal fov's degrees value [made into a string] to the command-line's code ['cline']. We can see that the horizontal fov calculated at 52.3015975216335 degrees, IS a correct value because the SUp vertical fovV at 30 degrees equates to exactly that when the calculation is done 'long-hand'...

As far as I can see, there is nothing in the encoding of this that should affect Octane's 'panning speed'... the OBJ xyz accuracy is set to 6dp
Code: Select all
v 3.482665 0.000000 0.224692
but the camera details are to ~14dp - surely that can't be the cause ?
_________________________________________________________
TIG
User avatar
TIG
Licensed Customer
Licensed Customer
 
Posts: 536
Joined: Wed May 12, 2010 1:25 pm

Return to SketchUp


Who is online

Users browsing this forum: No registered users and 7 guests

Thu Mar 28, 2024 11:32 pm [ UTC ]