VRML Loading screen

[Jam.hall]

Hi,

Doing a little project where i am taking a folder full of VRML files and loading them into a picture control. The problem with this is that it can take a bit of time to do depending on how many files there are. I was wondering if it is possible to build a loading screen for this.

Attached is the simpler VRML loader (ignore some of the case's in the case structure they will be used later), also attached is one of the VRML files

Thank you for your help

[Hillman]

Hi Jam,

Good Morning and I hope your well today.

Thanks for the post. 

The only way I could think to do it was based on time.. but it does give the impress to the user its loading.. you just need to make sure the loading bar takes long enough for the amount of files to load (which I guess you'll have a rough idea of file sizes (or you could) to calculate that). 

Note: to run this, please go into Loading Bar_LV86.vi and change the path for the 3D Demo.vi.

Please let me know if you are using LV8.6, otherwise I can resave it. 

Note: Also, on the first run no image appears because your code isn't in the run state. I had to modify 3d Demo to always LOAD case. 

Hope this helps,

Message Edited by Hillman on 06-12-2009 09:24 AM

[Jam.hall]

Hi James,

Thanks for the solution, I've modified what you gave me and adjusted it so it works in regard to the amount of files in the folder (takes no more than 1 second to load a file).

I've got another little problem, when there are lots of VRML files loaded the FPS of the 3D picture control really slows down to a stutter. Try loading the attached file with multiply copies of the Plate file, and you should see when you press the zoom button. I guess a computer upgrade will help solve this problem, but i was wondering there the is a more effeicent way of using the 3D picture control?

Cheers

[Hillman]

Hi Jam,

Thanks for the prompt reply.

How jumpy is jumpy for? To me, and the guys here, the zoom press and the object moving down is fairly smooth. I am running this on a Quad Core machine btw. The CPU does increase a bit when zoom is pressed. 

Also, when you say slow, you mean in time? I think it takes about 10 seconds to complete its move.

It is unusal to have an event structure within a case structure. Normally, you'd have two loops - a producer (for events) and a consumer - which in your case would be a state machine. Then based on the events, you can get the state machine to change states (and change states on its own without an event happening. This involves using a queue.. this may help with future development.

Thanks,

I will look into the picture control setup, and give you a few pointers later today? 

[Jam.hall]

Hi James.

I'm running a duel core machine, but i don't beleive the problem to be CPU based, its more GPU based my end I have a graphics card from the 1960's. Not sure what graphics card you chaps use but that may well be a reason as to why yours runs alot smoother.

When I only have one VRML file in my control, My machine can run the zoom function in about a 2 to 3 seconds (interestingly by my calculations it should take 1s but doesn't). If i put lots of VRML files into the control the zoom function takes several seconds to execute, to the stage where it is unusable.

I'm really interested as to why it takes longer, when i'm using a while loop with set characteristics to complete this function. I understand that if my mahine is struggling it should stutter, but it should still take the same length of time.

How does the while loop know when to update, does it just try to run as fast as possible, even if its held inside a while loop?

I understand about using a producer consumer loop, and eventually this project will end up inside a more advance structure. There is no need for this right now, as what we are looking is actually going to be converted to (quite a advanced) functional global variable, i'm just playing around with a few things right now.

A few pointers to help speed up the picture control would be great.

Thank you again

Message Edited by Jam.hall on 06-12-2009 05:57 AM

[Hillman]

Hi Jim,

Thanks for the post. I will look into the picture control this afternoon.

In terms of the while loop, it will iterate as fast as its contents will let it. If you have a wait for 5 seconds in there, it would approx iterate every 5ms.  I would consider benchmarking your code using a tick count vi, in a sequence structure  - placing your code in the middle frame. This will give you an idea of how long it is taken, and how it varies. 

You could also consider using a timed loop. This has a dt you set. But again, if its contents takes longer than this - it will slow to the maximum is can do. However, timed loops give you terminals such as 'is loop late' - which can be useful to know. 

I forgot to add the GPU - I was thinking along that line, sorry. I am using a NVIDIA Quadro FX 1700. 

I'll update you this afternoon on my thoughts for the performance, 

[Jam.hall]

Hi James,

I'm still having trouble with this 3D model application. Attached is the latest version with a few simple features such as open draw. The problem is because it runs so slow it takes a long time to complete this feature, making it kinda pointless. I'm running this on quite a good rig now

Intel Pentium 4 3.00Ghz Duel Core, 3.5 Gig Ram. and a Geforce FX 1400 Quadro, which is the type of machine we use for running solidedge (the program that made these 3D models)

I was just wondering if you could check over my code and find any ways to pick up the performance and if you have any ideas as to what might be slowing it down.

Also is there a method of setting the quality of the 3D picture control? For example Antialiasing? Or does the picture control work a different way?

Thank you again

From Jim

Message Edited by Jam.hall on 06-17-2009 03:22 AM

[Hillman]

Hi Jim,

Thanks for your reply, I am sorry for not replying sooner. Firstly, thanks for the kudos!

I ran your code, and the loading took around 10 -15 seconds. How does this compare with you? This is not size depend (space taken up on the Front Panel) but more the resoltuion.quality of the image. To speed up the loading and drawing time you could try lower qaulity models. 

The open lid works instantly. This is because you are only redrawing the image once. Does your rig react straight away?

The reason why the open draw takes longer is your currently asking it to redraw 65 times to generate a smooth image. This takes around 3-4 seconds. How does this compare for you? If you rig does react quicker, you could simply increase the movement size i.e. only redraw 32 times. If you rig reacts instaly then do you even need to redraw more the once to show the draw open? 

Please let me know your thoughts, 

Message Edited by Hillman on 06-17-2009 01:07 PM

[Jam.hall]

Hi again

Thanks for getting back to me

The loading isn't too much of a problem for me, because the code will be ran on a machine running for days at a time so 15 seconds is nothing really.

The open lid feature isn't finished yet, hence why it just opens instantly, because as you said it does just one simple translation. I'm currently working on some trig functions that will cause the lid to hinge, but there not done yet.

Currently on my rig (with all the models loaded) it takes about 100-200msto perform one interation on the while loop (now a timed loop) when redrawing the images. In order to get a smooth draw opening action I need to move the image quite a few times 65 times looks smooth but can take 10seconds+ to complete, this is were my problem really lies, cause this is far to slow. It would be great if I could get it down to 1-2 seconds.

I'm playing around now with the trade off between the amount of times I redraw and if it still looks good enough. But I can't really get it below 4 seconds and still look good. I'm not sure if I can make low quality images in Solidedge, I'm very new to it, but I will look for that. Will lower quality images increase the redraw time? Or just the loading time? Your right in saying that the size of the 3D control doesn't effect the speed of the machine which is odd in my mind, but handy.

I've switched the code now so that it doesn't use the 3D control but instead renders a window, as I have read somewhere that it is fast (I'm not seeing it).

I'm running pretty low on ideas how I could speed this up, I've taken anything complex out of the VRML's i.e.. Transparent objects which has increased the speed a little.

Attached is the new code I'm working from could you let me know how this runs on your machine, and any ideas you have on increasing my performance.

Thank you again

From Jim

Message Edited by Jam.hall on 06-17-2009 07:55 AM

[Jam.hall · Accepted solution]

Hi again,

I've got some good news. I've managed to find out why the VRML files are so slow (this is a little off topic but might help some people). The VRML file created in solidedge is very poorly structured and is very hard for any program (including LabVIEW) to process. So even a reduction in quality won't help to much (it will help but not as much as re structuring the VRML)

http://www2.hrp.no/vr/tools/chisel/install.htm

The link above is for a FANTASTIC program that will sort out you files for you I found that you have to be a little careful what options you turn on, as some will really drop the quality, and some will make the VRML unreadable.

From personal experience I found that the best option was under the reorganize section and is called "join shapes by color" this reduced the file size and polygon count by about 50%

play around with the other options but save a back up!

Oh and the above program is free!

Below is the finished application if anyone wants to have a peep

Thank you all for your help

Cheers