No use me commenting because I am still having problems like you after the last updates also. :) I have no idea what is wrong with Vue Pro. :o(

Which version of windows do you have ? I suppose you already updated the video drivers for your card, but windows 2000 or XP add a lot to stability of the program.

I have Win2k Pro with latest video drivers... Well I updated Vue Pro with the latest release, rebooted the computer, turned off background draw...restarted the tutorial am about 15 mins into it and here we go again...boy am I ever frustrated! I bought Vue Pro specifically for the OpenGL feature...I then bought a new computer with the best graphics card I could find (think I paid around $600.00 Canadian just for the card) all this so I could work with OpenGL....boy am I ever mad!~!!

The only thing I can think of that I could have wrong are the graphic card settings... In the ATI Compatibility settings I have as default ForceZ-buffer depth: Disabled Triple Buffering: Disabled Custom Settings: Anti-Aliasing - Application Preference Arisotropic Filtering - Application Preference Texture Preference: Performance Mipmap Detail Level: Performance Wait for Vertical Sync: Default Off TRUFORM: Always Off

No I don't think it's the card settings cause I just tried different ones and it still crashes.

Hmmmm.... That looks like a Windows issue. Suggestion? Go into your BIOS and turn Hyperthreading off. Win2k supports multiprocessors, not the HT trick. Supposedly that doesn't matter, but I've seen a lot of instances where it does. If that doesn't do it, which version of DirectX are you running? The newest video cards and latest drivers all assume you are running DX-9. And do you know -how- your video drivers were installed? The order can be critical. For most systems, the best I've found is do the OS install, then the chipset drivers, then the AGP drivers, then DirectX, and -then- the video drivers...that way they have all the code stubs to grab onto. If you know a friend with Norton System works, I'd ask them over to run WinDoctor on your system, just to make sure you don't have any Active X or COM registry keys hanging loose, looking for trouble to cause. Outside of that, all I can immediately think to do is completely remove VuePro, scour the registy to get any keys for E-on software (I don't see an icon for a RenderCow, so I assume that you aren't using them), delete anything from eon you find on your C drive, then reinstall.

Odd. I've never experienced anything like this. VuePro has worked perfectly for me from the beginning. Including all OpenGL features.

Of course, I'm running Windows XP.......I don't know if that matters here. It shouldn't.

But perhaps it does.

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=1674044

When will some of you realise that the problem is with Vue, not Windows, not RAM, not Video Card - but V U E !!!

I disabled Hyperthreading, DX-9 is running... Interesting, well I started working on the tutorial again just now and everything was going well until I started to move the camera, then the screens turned white again...I ctl/alt/del and got task manager and it showed I had tons of memory left (Total - 2095852, Available 1763272, System Cache 297748) and that Vue was only using a small amount (35,844 k). Then I tried to Printscreen and I get an error saying "Insuficient memory to create the bitmap. Close one or more applications to increase..." I have Enable background draw thread unchecked... Could it be Vue Pro trying to connect to the internet?

dawn; That is one of those' It shouldn't, but...' ideas. If you have a firewall program, set it to block Vue from accessing the internet, and give it a try. Since it did this only when the camera moved, that leans more towards being an internal Vue issue. You might want to re-enable the draw background thread and see what happens, as that process handles the window redraw. If things start crashing immediately, then there is something with either the video, or Vue's interfacing to it going on. A clean reinstall of Vue -may- correct it, then. And gill, I don't think that anyone has ever said that Vue (either flavor) lacks bugs and issues. But the hard truth is that the days of it being 'only X of Y' are pretty much over. There is just too much integration between OS and apps, and too much interdependency between hardware and software. If it is all Vue's fault, then there isn't a lot that can be done by anyone but e-on (and there should be large numbers of people having the problem). However, I have dealt with too many 'My Nifty New Proggie is a POS because it don't Work on my megabox waaaaaaaaaah!!!!! (profanity string of your choice)' maintenance tasks, only to find it wasn't the accused program, but an undetected hardware issue, and OS corruption, or configuration issue that was really to blame. A small core of people are having trouble; not a large swath. That tends to suggest a config issue. That doesn't mean there isn't a bad bit of code in the suspect app; there almost has to be for there to be a configuation issue. It takes all the elements to create the spell. But we can't fix that. What we can do is try and isolate just -what- configurations are giving people fits; there has to be some common factors there. And that doesn't include the fact that you can have a bum stick of RAM, with a single bit at the top of the stack that is weak, and so long as you run apps that never address that area, you will never know it. If dawn was having a CTD, that is what I would have suggested first, as Vue simply shuts down when it runs out of physical memory. Every potential issue that's eliminated narrows the field of investigation. And CG renderers like Vue, Poser, Cinema, and so on, stress a system more than just about any other app, even most games.

I totally agree with "gillbrooks": the problem is IN VUE PRO! Every soft on my machine works fine, except Vue PRo. Poser 5 works fine, Cinema also, Max also, and Maya also (I'll stop the list here). With OpenGL or not. The problem is in the Vue piracy joke. Quite the same as in the "olp" Poser 5, and Poser 5 SR1 (now they've changed it, with SR2/3/4, there is no problem anymore) Regards TJ PS: please note that there is a MAX 6 trial for free, and a Maya Education (?) for free. (Just for some.... in this forum who'll ask me how/why/but/is it? **; I CAN use all those :-) )

Dale B can you explain why on my computer Vue 4 doesnt give the problem. Poser doesn't give the problem. xfrog doesn't give the problem, bryce 5 doesn't give the problem. Games and dvd movies have no problems. Other 2D and 3D applications don't have a problem. I could go on and on but it is only vue Pro that has been giving me a problem of slowing down to a stand still or crashing. It looks as if your theory was right we would be having problems with other apps. I have to disagree with you and will always beleive it is a Vue Pro issue that hasn't been found or fixed yet.

I have to disagree with you and will always beleive it is a Vue Pro issue that hasn't been found or fixed yet.

Could be true. I don't know.

However, I do know that I've never experienced any problems like those described here.

Vue Pro has crashed on me about two (2) times since I've had the program.

If the fault lies in the program itself, then why would it work (almost) perfectly for some people, and not for others? This fact makes me lean towards some sort of difficulty with hardware/software interface issues.

I can appreciate that it's extremely frustrating to those that are experiencing difficulties. But I would not jump to conclusions about the cause..........jumping to conclusions is risky when it comes to PC tech.........

If I am proven wrong I will be the first to apologize. I agree it is something that hasn't been found and why some don't have a problem and some do is beyond me. That is waht we keep hoing to find. Explain why other applications don't have this problem and it is Vue Pro that is giving the problem. I do agree it could be hardware related but I think if it is then Vue Pro needs to find what ever it is the other application have done so it works with most all hardware and updated drivers. That is my sticking point, why don't other applications give the problems if it is hardware. Do we all buy an exact duplicate of your setup or Dale_B's setup. That don't make sense to me. :)

Here's hoping that you find a solution soon. Believe me, I've been there........with other applications. Many times over the years. When it happens, it makes you want to pull your hair out.

Or smash your PC. Or something.

I have gotten use to it but do understand others frustration when it happens. :O)

I'm beggining to suspect the anti-piracy measures too. Although it's difficult to see how they could cause these problems, as has been pointed out we know they did in Poser 5.

I have observed some odd behaviour from Vue Pro that certainly IS down to the anti-piracy stuff. If I hibernate my machine, with Vue Pro running, when I resume I get a message that Vue "has detected another copy with the same serial running on the network" and naming the localhost as the "other" machine. So for sure it doesn't work perfectly, if it can't tell localhost from a remote machine!

John

It would be nice if e-on could take out the anti piracy and let someone like Dawn that has a legit and legal copy of Vue Pro have a copy without anti piracy code and see if that might make a difference with her problems. Or someone else that is having the problem. Maybe put code in it that it would only be good for a set amount of days. Just a thought. :o)

I downloaded Vue 4 Pro demo today for testing and it crashed immediately so I believe that the problem is with the program; I have an ATI video card so maybe Vue has week/faulty support for ATI cards.

I've had some downtime to find out some more on the trail of what is causing the menu corruption and discovered some very interesting info, that I hope will lead to a solution from e-on.

Earlier in these threads, we were focusing on a leak in the resources like is seen in Win98. However, as was correctly stated by someone else, Win2K does not have a set limit to the memory that resources can use, rather using the entire memory store. This is true. However, I found out that it does have a limit to how much resources can be allocated, but that limit is not based on memory itself, but the number of handlers for that memory. They are called GDI Objects and win2K allows for 10,000 of these per process. Since Vue is one process, it gets 10,000. How does this relate? Well when an application reaches that number, it corrupts the resource index and basically causes havoc in the system such has been reported here.

With this new found information, through Google, I found out that the task manager has a way to find out how many GDI objects are being created (Go to Processes, then in the menu, hit View->Select Columns and click on the box next to GDI objects). Now next to each item, you should have a number that corresponds to how many handles each one uses. This is great, because now we can figure out whether VuePro is doing something crazy with them and what is making it to that crazy thing it does so well.

So I loaded up VuePro and loaded a scene. The GDI object count was 105, which considering the memory load and the type of program it is, this was pretty good, considering that Acdsee runs about 500 handles. Then I started to move an item across the screen (this being in OpenGL). For every inch I moved the mouse, the GDI objects would go up 30-50, which seems very unusual, but I figured it would take them back off after I let go. Nope, it left it at that amount. So as you can see, moving an object continuously or in the example that started this thread, I guess a camera, it leaks these handles badly. To me, this is a bug in VuePro, not in Windows and it's now something that can be duplicated as a demonstration. What I would like to know from the testers or people who ran VuePro on win2K if yours also has that same racking up the GDI counts. If not, then maybe it can be narrowed down even further.

This particular error (though there maybe many more) only seems to happen in OpenGL, which is practically unusable in Vue4, so maybe that's why it's stable. I know what the supporters will say. Just turn off OpenGL. End of problem. Well that's all fine and dandy as a bandaid, but I bought the program specifically for it's better OpenGL support, and have the proper video card to run it. I'm not an animator and I find the plant editor to be quite lacking, so this was a big reason for my purchase and something that makes my life so much easier before the chaos begins.

Dale B,
With all due respect, I'm glad I don't deal with my customers as you suggest, or I wouldn't have any. A lot of bugs are directly inside of the program. While it's true, that operating systems can cause havoc and their own brand of craziness, a company or software house should never just ignore substantiated claims without at least checking and doing a global scour of the code. Just because in your eyes, it's a small percentage, doesn't mean that there isn't enough people reporting the same difficulties to give an indication that it is indeed a software bug and not just a hardware or user problem. I'll be the first one to eat crow if I'm wrong, but I think the above is pretty strong evidence that there is more to this than just some's lack of knowledge or specs.

John,
I don't think the OpenGL issue is part of the anti-piracy code, but I wouldn't doubt there might be such bugs like the one you mentioned.

BTW, just for curiosity, I just loaded up Vue4, turned on openGL and after restarting it, loaded up a scene, moved on object and it did not have the same issue as VuePro. Hmmm... ShadowWind

Thanks for that info...I'm trying Vue right now with Task Manager up and watching what is happening...one thing I notice is that when I move an object it takes 98% of my CPU Usage for 3 or 4 seconds...Don't know if that is normal? Yup it went weird at 10,000 GDI...the interface went all weird and it froze... Memory usage is showing at 346,000K (I have 2 Gigs)and then I just tried to printscreen to show what is happening and I get an error saying Insufficient memory to create the bitmap. Close one or more applications to increase available.... Looks like you found my problem! Do you know if any of the memory utilities helps this until E-on can get it fixed?

Just found this: Here is the detailed process to watch the memory and handle counters for your process. This is applicable for Windows 2000 but should be same for Windows NT and Windows XP, as well. Open perfmon by clicking Start, Settings, Control Panel, Administrative Tools, Performance. Click the Add counters tool box(the tool with the + sign). It will display the Add Counter dialog box. Check the 'Use local computer counters' radio button. Select Process under the 'Performance Object:' drop-down combo box. Select the 'Select counters from list' radio button and select 'Handle Count' and 'Private Bytes' from the combo box. This box is a multiline select combo box. Select the 'Select instances from list' radio button and select your application from the combo box just below it. Press the Add button, followed by the Close button. This will open the perfmon window. You will see two graphs each for memory (private bytes) and handle count. Run your application and you will see the present status of memory usage and open handles for you process. If any of the counter values increase continuously without being stabilized, there are memory/handle leaks in the application. Here: http://www.codeguru.com/Cpp/V-S/debug/memoryissues/article.php/c4411 While testing Vue Pro, I just watch it increase continously until it reach 10,000 and froze.

I posted a reply over at Iloco's site, but will reiterate here.

98% of the CPU is not unusual really for any application at a given time. VuePro does seem to be always a bit on the harder side of the CPU, but not much more than any other similar application.

Insufficient memory is kinda a catch all for "I can't allocate this." It most likely means that GDI table, which seems to get corrupted when one process jumps the limit.

As far as Memory Managers, I doubt it, as they usually deal with straight memory, rather than resources. It's my understanding from the research I did today that applications are the only ones allowed to allocated/free entries from the handle table. I could be wrong on that, but that would coincide with the fact that none of them will touch the table in win2K, only read the amount.

Hmmm...innnnnnteresting... It isn't only -movement- that runs up the GDI handle count. A simple click on the left mouse button does it as well, and not with a consistent value; it ranged from 1 to 5 handles added. Either something is racking up handles, or it's picking up the switch bounces that the mouseware software buffer from the OS. And that -is- clearly a VuePro issue. I ran the GDI count up to around 1500, closed the task manager, and got the redraw window mess. But a switch to 4 view and back cleared it. And no offense taken; but the hard truth is that I do not have the source code, and can do nothing about any bugs in Vue or VuePro. E-on has to do that. All I can do is suggest courses of approach involving those things the user actually has access to. At worst this eliminates possible outside causes, and may highlight the possible problem(s). Ignoring the people who have trouble is another option (since I can't 'fix' things), but that doesn't really solve anything. And the last thing needed is inaccurate bug reports; that could really cause trouble for all concerned... Besides, if this was in a business context, -I- would be doing all of that, not telling the user 'do this, this, this, and try that while you're at it'. ;P

Fair enough Dale and I'm sorry if I got a little testy as well. It's just frustrating to see the potential and not be able to use it and watch others who can.

I am glad to know it's doing it on your machine as well. At least we can all agree on that issue now...

I can sympathize... Remember those first couple of generations of VIA mobo chips, and all the Intel specific coded apps they would throw an absolute conniption over? And the memory mistimes? And the sad excuse they had for drivers? Frustration and I have sat across the battlefield for a =looooooong= time, now. Now that this has come to light, it makes me wonder if some of the trouble I've had with VuePro CTD'ing at the start of a distributed render is fully related to memory. If there is a code section that assigns GDI handles and doesn't free them properly...maybe it assigns them for -other- outside events. I think I'll do a little reseach on this...

I have tryed to get to 10,000 but at 1,198 my Vue Pro has come to a crawl and doing as always slowing to a crawl. If I minimize the Vue Pro window and bring it back maximized it takes forever to load the scene. It is proably some the same problem but I will leave it to you guys who know code and how an application is suppose to work. I do believe you are on the right path of finding some of the problems. I sure hope you are. :o)

ShadowWind,

replicated your observations on XP, the handles just go up and up. Somebody posted a few months ago, that when they loaded a bitmap texture they got the GDI imagelist of current icons/cursors/buttons and that reminded me that I'd written some code that caused that problem once. It was to do with GDI resources being low, but it wasn't because I wasn't releasing them, it was because I was destroying handles that belonged to the system and not my app, but was incorrectly documented in the Win32 SDK. I eventually found the answer hidden somewhere in the MSDN knowledgebase, but I can't for the life of me remember what API call caused the problem :( Anybody know where I can buy some new, reliable, memory for my head?

Anywho, that also would explain why some of us have problems and others don't, it's workflow related. I plan on paper, model in Anim8or, animate figures in Poser and don't do much moving of objects at all in Vue, I already know where and how I want things so movements, rotations and scaling in one of my scenes are probably minimal compared to most people.

I really hope this thing is cracked soon, I get a huge amount of fun out of Vue and it really spoils it that others are so unhappy with it.

John

I rebooted and opened a new window in VuePro. I loaded an atmosphere this time and two terrians. I was able to right click in side view window and move it around and the GDI went up from 50 to 70 with each move. I kept moving until I reached 9.999 and it locked up. This didn't take long to get to 9,999. John I agree with you 100% that I hope Vue is cracked soon and we can work with it without the problems some of us have been having. :o) I have always prefered Vue over Bryce and I really like playing in it when it works right.

Ok, just loaded Vue 4 and tried this with 30 summer cherrry trees and 3 terrains with volumetric textures on them...moved everything around as I did in Vue Pro (camera, window views) and it was staying consistant around 176...would go up and down 2 numbers but that's all...(where in Vue Pro it was jumping up around 50 each time) With OpenGL on and background thread off (same settings in both). Vue Pro's OpenGL looks way better than Vue 4...BTW Also my memory usage in Vue4 was way lower than in Vue Pro and I had more items and polys in it. Vue 4 - 52,372 k Vue Pro - 346,000K I also tried Poser 5, loading MilDragon and V3 and it was stable around the 288 mark no matter what I did. I'm excited, knowing that perhaps it can be fixed soon and we will all be happily rendering :)

Oh just want to say that I don't really hate Vue Pro, I think once this issue is fixed it will be awesome software for it's price...I was really frustrated when I wrote my first message and was expressing my frustration :)

Just ran a quicky test with the functional part of the rendergarden. There was no effect on the GDI handles either loading the Poser figure or running the network engine (as there shouldn't have been...but better certain); it was all related to the actual interface (which is a relief; that should be a much easier fix than having to rip out the renderer's guts). It also explains why the Cows seem so well behaved; they don't have an active GUI front end And I -think- I know what you are referring to John, but I can't for the life of me remember what it referenced... Also, we share a similar workflow; most of my motion work is done in Poser, and the rest is adjusting Vue around that motion pathway. This might be a big clue, it might it might....

Sorry, forget that, it was regions that caused the prob, can't see any way that would be relevant to these problems. Just having a senior moment.

John

Maybe so, but we -do- have an apparent across the board event that shouldn't be happening. Does anyone want to forward a link to this thread to Lynn, so we know that E-on sees it?

Dale, if E-on read their own forums, I think they know by now! John

I posted on their forum this information, don't know when they will read it though...

Look a little closer; Walther posts on the 26th Steve Bell replies on the 30th Walter thanks Steve for his quick response, a bit earlier on the 26th Pascal replies on the 27th Steve replies again, 24 hours before his first response... I think we should all synchronise our PC clocks now. I've got 01:56 on the 2nd, what time do you have? John

Hey Iloco's post, that I was replying to just disappeared. Maybe he won't really post it until tomorrow? John

"lol" I saw that after going back. It is 7.58 PM April the 1st here where I am at. :) That is why I removed my reply. I was wrong with what I thought I saw. :o)

WE must be pretty well synchronised as we are posting and deleting at same time. :o) I am going to start waiting 15 minutes before replying so we know what is what. :o)

Well, it being 02:10 here, I'm turning in for the night. John

Nite John, I better not wait 15 minutes or you might not see this. :o)

I am glad I found the information, and I don't want to toot my own horn. It's juat a relief to see that this has been locked into a real bug and real scenario, so that perhaps fixing will come soon. It's been frustrating, especially since VuePro in itself was worth the money. When it runs, it is sweeeeeeeeet! The only problem I've had after the second update was just this particular bug. Otherwise it's been very stable until the chaos. So if that's fixed, I should be in heaven.

You are right about the workflow. There is very little that I plan in advance, beyond a rough concept, and then that is more of a picture in my mind. The fun for me is to tinker with different things, experiment with FX like Pepper's Ghost, and other things. So basically my whole Vue experience is moving things around and trying different combinations of elements to tell the story I want to tell. I find that if I start with a plan, I usually find other interests and wind up with something different anyway. Maybe in the truly pro world people don't do that, but it's the way I do it even on the commission works, which fortunately I've had a lot of creative freedom on so far.

And yeah, I remember the old VIA boards, had one, hated it, doused it in gasoline and burned it at the stake. Okay, well maybe not that bad, but I traded it in for a Pentium later on. I realized it wasn't Athlon's fault, but like this, if it doesn't work, it's losing time and money, so I had to drop it. Maybe in the future would go back to it. Don't know.

Guess the ball is in their court.

If this found to be a cause of our problems with Vue Pro you have every right to toot your own horn. I hope e-on confirms this to be true and we can have a piece of software that we can enjoy instead of hating. Thanks ShadowWind for you time and effort trying to help all of us with the problem. :o)

I have an ATI video card and Vuepro works terrible on it. I have Nvidia card and it works alittle better. Its e on.

No one has repled to ShadowWinds post yet at e-ons site. I thought it would got some attention by now. Maybe they are not checking the new forums yet.

I didn't have any of these problems for a long time....because I stayed on the second update for Pro. The only problem I ran into was losing textures on some items when rendering in superior or ultra...quite frustrating, I'll add. This always happens with audity's grass, for some reason. But about 3 weeks ago I finally updated to the latest Pro fix (I did the biggie, to capture all the updates in between) and I'm having terrible slowdown. It has only frozen on me a couple times, but as my Vueing time is so limited now, it's created a lot of frustration. I have OpenGL turned off even in Pro, as it worked with my card, but slowed down response. I am running W2K, sr3, everything else (about 25 proggies) run like champs on it, so thanks to you guys who have figured out what the cause looks to be. Now...if only Eon will listen!!