optimal size of a 3DS file

I am trying to import a 3d graph object in 3ds format. But when I import it using Visual Tool, Flexsim ceased to response. The file is about 130kb. Is there an optimum size that we should reduce the file size to?

Thanks

David

David,

That size should not be a problem. We have imported files of 25Mb. Have you tried to import it into AC3D and then export it as a wrl and then import that file?

Steven

No. I have not. But it is still worth to try. I will let you know my result. By the way, do you think will this importing process constriants by the memory on the graphic card?

I have one notebook that has only 64M and another 512M

David

David,

I guess there are different things you should keep an eye on, if you like to import 3D Shapes, where it does not matters if you use *.3ds or *.wrl.

In one of my projects in the past the customer gave me an 3D Shape *.3ds which was 650 MB, because he got it directly from Solid Works and every detail was in the shape (screws, parts inside, etc.). This happens if you get a part directly out the construction program (CAD).

So what I did was to delete a lot of parts you can not see and I had an object around 25 MB.

Than I used AC3D and selected the parts/shapes which are visible from the outside and in my eyes where important for visualization purposes. I hide this shapes and than made a polygon reduction within AC3D with the other parts/shapes. I played around with different values for the percentage of the reduction. After this I unhide the outside parts/shapes.
I exported the whole shape at the end as *.wrl in Flexsim mode with material zero and size 1,1,1, position 0.5, 0.5, 0.5 as described in another thread.

At the end I had a shape which in my eyes still looked good but was “only” around 8 MB.

This shape I used in my model and the speed was okay. I am pretty sure that I can not have hundreds of this shape in my model, but up to 6 was okay on my computer.
I guess, but I am not an expert, that the memory of the Graphic Card is used for the number of polygons and for the number of textures. So if you have a lot of polygons and a lot of textures the memory will fill up.

Anyway, what I am trying to say is that in my eyes the following things will influence the navigation speed in the model:
- size of 3D Shape.
- number of 3D Shapes in model
- number of polygons (which is mainly the size of the Shape I guess).
- graphic card (gpu speed, memory).

I am not sure, but hopefully this post gives you some hints.

An alternative way would be to use textures on an object to make it look like the original shape. Also some work, but the idea behind it is again to try to reduce the number of polygons.

Speaking about this subject: Would it not be nice to have an option in Flexsim to switch of the calculation of the views (ortho, persp).
In Flexsim the speed difference in having a view open or not is not as dramatic as in other simulation packages, but there is still a difference, right?
As far as I understood is the graphic card in Flexsim calculates the views (OpenGL) and not the CPU as in a lot of other simulation packages. That’s why you have a big speed improvement by switching of the views.
But I guess that the CPU still needs to do some calculation and communication with the GPU (graphic card) to make the views. Right?
I am not an expert, but if there would be a switch/option for not calculation the views, just calculate the run. Would this be a speed improvement for the simulation run?

Anyway, maybe one of the Flexsim experts can give us his opinion.

Take care
tom the (A)tom

Tom,

If I understand your the last part of your post correctly, then the problem is already solved. Simply closing all of the view windows will effectively stop any 3D calculations that have to do with the view windows and will significantly speed up your simulation. The only exception that I know of for this is if you are using Collision spheres. Because they need an updated 3D location at fairly constant intervals they will update the views on their own whether they are open or not.

Hope this helps,
Brandon