Blendigo Solidworks variant
Jeff I think you will find you need to up the resolution to make sure 'curvy stuff' exports accurately
I find this to be an issue with the vrml export too.
Sometimes the way SW forms the triangles produces unfortunate results that don't look flattering seen in other programs where the normals are concerned...you get sort of ridges or pinch points here and there
In some cases even at the highest res I have seen obvious triangles in a render of a glossy car body for instance using blenders internal render.
These unwanted translations are very hard or impossible to fix satisfactorily post export in my experience.
Possibly STL has more accurate output - or at least you can control it better
I think ono works on a 64 bit build and this will alleviate the file size problem. blender has a 64 bit version too...not sure about sketchup
Also consider suppressing the swoopy or fine detailed parts in SW and just exporting the square stuff at coarse res - and then follow up with higher res for the necessary items - I guess you would need to 'include' them.
With the machining centre when I wound up the res to capture fine detail well the file was enormous and unmanageable in blender but on inspection there were only actually a few conspicuous parts that needed it
If you do all high res the file size is maybe 3x whats adequate..
I find this to be an issue with the vrml export too.
Sometimes the way SW forms the triangles produces unfortunate results that don't look flattering seen in other programs where the normals are concerned...you get sort of ridges or pinch points here and there
In some cases even at the highest res I have seen obvious triangles in a render of a glossy car body for instance using blenders internal render.
These unwanted translations are very hard or impossible to fix satisfactorily post export in my experience.
Possibly STL has more accurate output - or at least you can control it better
I think ono works on a 64 bit build and this will alleviate the file size problem. blender has a 64 bit version too...not sure about sketchup
Also consider suppressing the swoopy or fine detailed parts in SW and just exporting the square stuff at coarse res - and then follow up with higher res for the necessary items - I guess you would need to 'include' them.
With the machining centre when I wound up the res to capture fine detail well the file was enormous and unmanageable in blender but on inspection there were only actually a few conspicuous parts that needed it
If you do all high res the file size is maybe 3x whats adequate..

whats with the shit attitude man..
you are wanting people to finish an exporter right now just for you...
do you want your fillets to look like chamfers and your holes to have fillets cos the normals/smoothing is wrong?
do you give a f*** about anyone who wants to render something else?
where is your community spirit..you get this all for free anyway..jes

Last edited by Big Fan on Wed Aug 08, 2007 7:30 pm, edited 1 time in total.
When exporting vrml straight from SW changing the detail level in the options adjusts the fineness of the tessellation like you say. Not sure if it by default exports the normals but if you turn on normal smoothing in Indigo it would smooth those little triangles out into a nice smooth surface.
The property that is set for this actually will export boxes etc. with very few triangles but as you get curves it generates very fine so it kinda does what you say on it's own.
When creating and exporting the tessellations the settings in SW do not apply. The 'fineness' can be set. I can export model assemblies up to a certain size just fine. To export anything large the tessellation has to be rather coarse and without the normal smoothing it look very bad.
Maybe I should go the route where I let SW export vrml to me and I in turn convert it into Indigo. Hmmm? maybe another option. I should at least do an experiment and see if the normals come out properly that way. You've inspired me

The property that is set for this actually will export boxes etc. with very few triangles but as you get curves it generates very fine so it kinda does what you say on it's own.
When creating and exporting the tessellations the settings in SW do not apply. The 'fineness' can be set. I can export model assemblies up to a certain size just fine. To export anything large the tessellation has to be rather coarse and without the normal smoothing it look very bad.
Maybe I should go the route where I let SW export vrml to me and I in turn convert it into Indigo. Hmmm? maybe another option. I should at least do an experiment and see if the normals come out properly that way. You've inspired me

ouch,
big fan, please ignore my posts because i think you are just misunderstanding me anyway. i already use jeffr's obj exporter and if nothing else ever came from this i'm already quite satisfied with that.
Jeffr, i'm saying that maybe just find the format that's best to export first, then worry about tweaking. that way you can concentrate on one thing at a time without overheating your brain with the small details. at least thats how things work best for me. ie. get good with lighting then work on materials, if you tried to work both at the same time you'd go nuts because each affects the other.
big fan, please ignore my posts because i think you are just misunderstanding me anyway. i already use jeffr's obj exporter and if nothing else ever came from this i'm already quite satisfied with that.
Jeffr, i'm saying that maybe just find the format that's best to export first, then worry about tweaking. that way you can concentrate on one thing at a time without overheating your brain with the small details. at least thats how things work best for me. ie. get good with lighting then work on materials, if you tried to work both at the same time you'd go nuts because each affects the other.
Jeff I dont think you will find any advantage using vrml over obj or even stl provided you can get the uv and colour info but I guess its worth investigating
I think its indigos own normal interpretation thats the limiting factor rather than SW fault -ie you just need to need to stay above a certain tesselation fineness for it to be acceptable
at a guess you want small holes to have at least 12 faces to have the appearance of being round
its always going to be a problem if the parts are large but the detail is small and you want to view the detail in the render view
perhaps this is a memory size issue rather than a fault with what you are doing
how big an assembly are you trying before the coarseness of the tess makes the normals ugly?
also are you using the 3gb switch for 32 bit or just usual when you export? perhaps you can sqeeze some more fineness out using that...
maybe you just make the exporter and recommend 64 bit SW and Indigo for large assemblies or over a certain size

If you make an 'include' function available in the exporter people can chain together large or difficult assemblies if they want...it just isnt as convenient
@xrok1
I am not in the habit of just ignoring people who are rude and wish to continue to be rude rather than pull their heads in
I think its indigos own normal interpretation thats the limiting factor rather than SW fault -ie you just need to need to stay above a certain tesselation fineness for it to be acceptable
at a guess you want small holes to have at least 12 faces to have the appearance of being round
its always going to be a problem if the parts are large but the detail is small and you want to view the detail in the render view
perhaps this is a memory size issue rather than a fault with what you are doing
how big an assembly are you trying before the coarseness of the tess makes the normals ugly?
also are you using the 3gb switch for 32 bit or just usual when you export? perhaps you can sqeeze some more fineness out using that...
maybe you just make the exporter and recommend 64 bit SW and Indigo for large assemblies or over a certain size


If you make an 'include' function available in the exporter people can chain together large or difficult assemblies if they want...it just isnt as convenient

@xrok1
I am not in the habit of just ignoring people who are rude and wish to continue to be rude rather than pull their heads in

You may be right. I'll do some experimentation.Big Fan wrote:...you just need to need to stay above a certain tesselation fineness for it to be acceptable
It's not dependant on size actually. Even exporting one ball and giving it a specular reflection. The reflection is messed up. ie reflections not where they should be, black areas where there should be reflections. Keep in mind this is only when the indigo option for smooth normals is set true. Not setting this the normals don't come into play and the reflections are all proper you just have to have the tessellation fine to get a smoother curve. But then you run into memory issues. That's how i got onto this winding road....how big an assembly are you trying before the coarseness of the tess makes the normals ugly?

3gb switch? Don't know what that is.also are you using the 3gb switch for 32 bit
You may have sparked another inspiration. I already use the include to bring in the obj assembly into Indigo. Wonder if I could push more through if I saved each individual part as an obj that was automatically included by the Indigo file.people can chain together large or difficult assemblies if they want...it just isnt as convenient![]()
Thanks
Cheers
Jeff
P.S. I've found the api outputs I need to go with no camera and just the viewport. Not sure if you'd be interested. I know there's lots of extra cool things that can be done in Blender.
well I do like blender for all sorts of reasons..
but of course I'm interested if it makes life easier
ok here is a link to info about the 3gb switch compiled by W.Tiffany
this is reasonably well known if you frequent the comp.cad.solidworks newsgroup at all
http://www.kcswug.com/documents/3gb_swi ... _three.pdf
there are some knowledge articles at the MS site too
basically windows only lets an application run in 2gb of space and keeps the other 2gb for itself - actually about 1.65 gb is the appl limit
with this boot.ini mod you can set it so that windows limits itself to 1gb and gives you another 1gb to play with even if you dont have the physical ram - see the pdf
in my case I added this line
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional 3GB" /3GB /fastdetect /userva=2900
beware though you need the ms patch first if you are not using SP2 and some drivers dont like it
..it does sound as if there is a normals problem though..you shouldnt need to be exporting at super res to disguise the lack of functioning smoothing
seems some of the normals flipped orientation during your processing
this is what causes the black bits - most likely it messes up the uv orientation as well which is why they are not mapped correctly
in blender there is a tool to recalculate normals outside/inside..maybe there is an equivalent call in SW?
but of course I'm interested if it makes life easier

ok here is a link to info about the 3gb switch compiled by W.Tiffany
this is reasonably well known if you frequent the comp.cad.solidworks newsgroup at all
http://www.kcswug.com/documents/3gb_swi ... _three.pdf
there are some knowledge articles at the MS site too
basically windows only lets an application run in 2gb of space and keeps the other 2gb for itself - actually about 1.65 gb is the appl limit
with this boot.ini mod you can set it so that windows limits itself to 1gb and gives you another 1gb to play with even if you dont have the physical ram - see the pdf
in my case I added this line
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional 3GB" /3GB /fastdetect /userva=2900
beware though you need the ms patch first if you are not using SP2 and some drivers dont like it
..it does sound as if there is a normals problem though..you shouldnt need to be exporting at super res to disguise the lack of functioning smoothing
seems some of the normals flipped orientation during your processing
this is what causes the black bits - most likely it messes up the uv orientation as well which is why they are not mapped correctly
in blender there is a tool to recalculate normals outside/inside..maybe there is an equivalent call in SW?
Last edited by Big Fan on Wed Aug 08, 2007 1:22 pm, edited 4 times in total.
Big Fan,
i sorry, i wasn't trying to be rude i guess i should have put LOL after my first statement, but i thought jeffr would take it right after our previous posts.
So... lets get back on track helping jeffr out. i'm sure you're going to be much more help than i, but hopefully i can provide a few ideas and a little perspective.
P.S maybe this conversation should be moved back to other exporters you might find more SW looking there than in the blender thread.
i sorry, i wasn't trying to be rude i guess i should have put LOL after my first statement, but i thought jeffr would take it right after our previous posts.
So... lets get back on track helping jeffr out. i'm sure you're going to be much more help than i, but hopefully i can provide a few ideas and a little perspective.
P.S maybe this conversation should be moved back to other exporters you might find more SW looking there than in the blender thread.
I am not helping jeff out. I can't help him.
I do not know the SW API and his macro doesnt work with SW05.
I already said that
I'm only passing on my experience of vrml in blender to jeff to perhaps lend insight into his normal issue
Possibly he could try importing and exporting the obj again through another program and the normals might correct themselves.
This has worked before for some folks - of course it doesnt help with efficiency
Yes by all means please take it somewhere else...
I do not know the SW API and his macro doesnt work with SW05.
I already said that
I'm only passing on my experience of vrml in blender to jeff to perhaps lend insight into his normal issue
Possibly he could try importing and exporting the obj again through another program and the normals might correct themselves.
This has worked before for some folks - of course it doesnt help with efficiency
Yes by all means please take it somewhere else...

Who is online
Users browsing this forum: BLEXBot [Crawler] and 56 guests