Here is beta.s
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...
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.
Now the user 'paints' with his desired materials.
The outside [front] faces are colored 'red'.
The inside [back] faces are colored 'green'.
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.
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'].
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.
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 ???
--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
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
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
v 3.482665 0.000000 0.224692
Users browsing this forum: No registered users and 24 guests