[Plugin] UV Toolkit
-
huh!.... appear to be no temp path set in the environment variables...
Type this into the Ruby Console:
ENV.each { |k,v| puts "#{k.inspect} : #{v.inspect}" }; nil -
ENV.each { |k,v| puts "#{k.inspect} : #{v.inspect}" }; nil
"PATH" : "/usr/bin:/bin:/usr/sbin:/sbin"
"DISPLAY" : "/tmp/launch-MHvctR/org.x:0"
"SSH_AUTH_SOCK" : "/tmp/launch-Vm9A84/Listeners"
"Apple_Ubiquity_Message" : "/tmp/launch-bpbd2b/Apple_Ubiquity_Message"
"Apple_PubSub_Socket_Render" : "/tmp/launch-33EI0M/Render"
"COMMAND_MODE" : "unix2003"
"IG_ROOT" : "/Applications/Google SketchUp 8/SketchUp.app/Contents/Resources"
nil -
My suspicion is confirmed.
But I don't understand - it gives no info about where the system temp path should be.
Exactly what OS do you have?
-
Lion 10.7.4
-
Could it be because it is installed in the root? just guess.
-
When you installed Sketchup did you accept the default folder location ?
The ENV variable should contain lots of data - like your user-paths, temp/tmp folders etc... -
@sepo said:
Could it be because it is installed in the root? just guess.
I have no idea. I'm not that familiar with OSX - but this is the first time anyone ever reported an issue like this. I've also never seen a complete lack of environment variables...
-
@tig said:
When you installed Sketchup did you accept the default folder location ?
The ENV variable should contain lots of data - like your user-paths, temp/tmp folders etc...Yes
-
OK, I solved problem now. I created the account and moved all software to that account and now everything loads fine so far. So it looks like Mac does not like when some stuff is installed on root. It seems to me it requires creating account.
Thanks for your help Thomas. -
Well, I didn't manage to provide too much of a solution. I'm glad you worked it out in the end, because I was at a complete loss. Thanks for reporting back. I'm making a note of this that environment variables might be completely missing.
On a sidenote - I do generally think that running as root is not recommended out of security concerns.
-
Yes you are correct...lesson learned. I was just messing about as you can do more stuff from the root than from the admin account. It is interesting that all licenses did not transferred automatically I had to reinstall for Thea and license for Twilight was not recognised so I need another one. MS and Adobe went without hitch.
On the windows side I did not have any problems.
In any case you tried to help and that is appreciated.
-
Hi,
I used the plugin to use the "Frontface Material to Backface", and it worked fine, but when I check for errors in SU, it says: "The front or back texture coordinates for CFaceTextureCoords (48) is not valid" for every face and when I click fix, it reverts to the way it was before using the plugin (no textures on the backfaces).
Any ideas? Or is this normal?
Thanks.
-
@vanman said:
Hi,
I used the plugin to use the "Frontface Material to Backface", and it worked fine, but when I check for errors in SU, it says: "The front or back texture coordinates for CFaceTextureCoords (48) is not valid" for every face and when I click fix, it reverts to the way it was before using the plugin (no textures on the backfaces).
Any ideas? Or is this normal?
Thanks.
I don't know without seeing the SKP file in question...
My FixReversedFaceMaterials flips faces and reuses the back-material that was incorrectly 'looking out' so it's now on the front-face that's now changed to be correctly 'looking outwards'... if you get my drift... try that and see if there are errors... -
Cool thanks. I'll give it a try.
-
Can you post a sample model please?
-
I've PM'd you.
Thanks for the help. -
@vanman said:
Hi,
I used the plugin to use the "Frontface Material to Backface", and it worked fine, but when I check for errors in SU, it says: "The front or back texture coordinates for CFaceTextureCoords (48) is not valid" for every face and when I click fix, it reverts to the way it was before using the plugin (no textures on the backfaces).
Any ideas? Or is this normal?
Thanks.
Huh! That's odd. Don't know what's going on here.
Never seen that before - and the model looks to be fine. I'll have to investigate. -
Is there a very tiny facet that returns invalid coordinates, that are regarded as the same because of the 'rounding' of its very close vertex-points ?
I just had a perhaps somewhat similar issue with my Octane Exporter [on their forum]... Someone has made a very small object that would have had overly tiny facets when created, if they hadn't scaled it up to process and then back down when done - the small facets can exists, it's just making them that's the issue. So far so good... now they exported it to OBJ format for use in Octane and there were tiny holes in the object when it rendered. Octane requires the OBJ to be in 'm' and have triangulated faces. In processing the meshes my tool uses the API methods to triangulate the mesh's faces. I now think that what was happening was that the triangulation of some tiny quad faces resulted in two triangulated facets that are so small that they have two vertices that 'round' to be at the 'same point' [the OBJ format is set to 'm' 6 d.p.] - therefore that new facet can't exist as its only a 'line' at best, and the two parts can then be missed, out leaving a small quad shaped hole when the object is reformed from the OBJ data...
This could of course also mess with the tiny face's texture mapping ? -
It's a 1:1 scale building with textures...
-
BUT might it still not have a very tiny textured facet somewhere that is thereby tripping things up ?
Advertisement