Darn this stupid program! I am working on the Escher tutorial...I have a simple daytime sky, and 3 squares in the scene...been working on it for 15 minutes...then my mouse started going jerky and the interface went weird, I can't even save cause the interface is so weird. This is on my new machine (which I bought specifically to use Vue Pro with) and nothing else being used on it... Intel Pentium 4 3.0GHz 800MHz FSB Processor with Hyper-threading 2GB PC3200 400MHz DDR Memory Asus P4P800 Deluxe Intel865PE H-Threading 800MHz ATI RADEON 9800XT, 256MB DDR II, AGP8X, DVI, TV OUT There should be no reason at all that this is hanging like this!!! I'm almost at the point of going back to Bryce!

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.

• agiel - www.linfa.net

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.

Something To Do At 3:00AM 

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

That's exactly the sort of problems I and a few others get. Take a look at this lengthy post from a few weeks ago. It was never resolved. The last twice I've wanted to create a 'quick background' for some Poser work, I've reverted to Vue D'Esprit.

Gill

       

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

Gill

       

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.........

Something To Do At 3:00AM 

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.

Something To Do At 3:00AM 

Or smash your PC. Or something.

Something To Do At 3:00AM 

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!!

Sgiathalaich

Djeser, E-On did listen and promises to fix the OpenGL/handle problem that was causing the menu/interface corruption. That has been in every version of VuePro since the start that I'm aware of. I haven't experienced the slowdown, though it might be related to that as well, not sure. I haven't been able to sit down with VuePro long enough to get really into it deep enough where I might see it. Hopefully when the next patch is out, that will allow me to do so. shadowWind

I mojoworld, lightwave, deeppaint 3d, poser, photoshop, wcs 6.0 user and been thinking about getting vue because of the Dead City images in the gallery and notice this thread. For one thing, I don't think HT is problem unless Vue has troubles with multiple processor - logical or physical HT threading appears as 2 cpus.. In Mojoworld HT is a great benifit, because it gives you about 50% more computing power when rendering in 2 sessions. I think the main problem here is choice of Video card. ATI's are notorious for bad activity with OpenGL profession graphics. Lightwave has is good example. I have HP Pentium M notebook with ATI 9200 on it and if I leave Mojoworld alone on it - windows XP will lock up with ATI driver error. NVidia user to that about year ago but since been fix. This thread is a little concerning to me.. is this an isolated case or does a lot of people have issues like this.

I am using Nividia and the latest drivers and have had the above problems that were being discussed. You must have missed where it said e-on has acknowleaged that it as a problem that ShadowWind has found. It was not related to viedo cards. :o)

ïÏøçö

iloco, thanks for your response.. When it states turning off OpenGL - I assume this is done inside the application and also what does this means. Does Vue use Direct X when Open GL if off or does it just use GL graphics.

What is the impact of this problem, does it make Vue hard to used. If so when will E-on have a fix.

P.S. I am a programmer by profession and from ShadowWind's comment this problem sounds like a memory leak / resource leak in Vue. E-on should run something like Bounds checker on this operation. What I can see on the image of screen that that is not many graphics object being display, so something must be serious wrong in logic to cause over 10,000 gdi objects to be used. My guess even if windows allowed more, it would still have the problem - just take longer to cause the symptoms.

I be watching this thread, this type of issue must be resolved before I can consider the package.

As I stated above I am dumb when it comes to understanding how software and code works. I only know when its not working as it should. I am sure ShadowWind can explain what was found, and the more like you the better when it comes to finding the problems for people like me that don't know how. Thanks for taking interest in this thread. :o)

ïÏøçö

I am slightly confused now.. how serious is this problem, is Vue uauable with OpenGL off or not?

I have an ATI card (AIW 9700 Pro) and I have no problems with the OpenGL itself. Djeser has brought up a point at the forums of eon about non-OpenGL also slowing the system down and running out of GDI objects at 10,000. I don't know the specifics of that bug right now, but I would imagine it's a similar problem. On mine, OpenGL and the program works fine until that leak hits 10,000 GDI. At that point, windows starts to be corrupted and menus and interfaces disappear, followed by a full system meltdown. For some people who plan ahead and do very little movement in the program itself, this may never be seen, as evidenced by some of the beta testers who did not see this until it was brought up. However, if you are trying to do a complicated camera setup like dawn above, it can be as quick as 15 minutes to reach this threshold. I've had anywhere between 15-60 minutes personally. BTW, I have an ATI AIW 9700 Pro and it works like a champ until that threshold. Eon has confirmed that it is not a hardware or driver issue, but an actual issue in the software (a resource table leak), that they will address in their next revision. I don't know when that revision will be, but given the amount of people with the problem, I hope it will be soon. So the answer to your question is unfortunately yes and no. It depends mostly on your workflow until the bug is addressed.

To update you...this last Pro update has become a disaster. I have a lot less time to work on images these days (due to a new and very time-consuming job), and when I took a break yesterday afternoon to work on an idea, Pro crashed on me 3 times. I can count on one hand the amount of crashes I experienced from the time I installed it in early Oct to now...prior to installing the update. I am finding Pro almost unusable now, and since I have been using it almost exclusively (rather than Vue d'Esprit) since I installed it, I'm more than a bit disappointed. I have OpenGL disabled, background draw turned down, all the usual stuff. My image had about 2mill polys, and when I import a Poser figure (which I do all the time!) I get the "Vue Pro is generating an error" window. I can never find any error reports, however. Frustration level is exceedingly high now.

Sgiathalaich

From the technical stuff and this thread it sounds like bug in Vue. Any idea when this next revision of Vue is coming out. Maybe it will be a 4.1 version or something like that.

They haven't said, though they are very fast about patches and revisions for things like this. So I wouldn't expect it will be too long. VuePro is 4.5x, which I guess they are on 4.52 since they mentioned 4.53 would be the next official release, though they usually put up beta releases in the meantime.

Djeser,
Hmmm, I can imagine your pain. I haven't had much time to play with the newst revision of VUePro, but I will be doing so tonight/tomorrow and can let you know if I see anything there. Is the error the same all the time in that same scene? or is it one of those random type things? You had mentioned the GDI was affected, how so? Can you import another poser figure or does that crash too? I did notice in the little I played with the new revision, that it seemed to be a might more sensitve about Poser objects than the other versions. I am not trying to cop out, but maybe in the short term, if you can go back to the previous version, might be good, but yeah, it would definitely be something that they need to fix. If it's giving an eon error than it's most likely on their side, as even eon said this.

ShadowWind

If I knew how to go back to the previous version, ShadowWind, I would surely do so!!! The slowdowns happen after about 5 minutes of working...whether adding objects, importing objects, or just working on textures. No exact moment or action sets it off. I tried monitoring the GDI like you all mentioned above, and the numbers just go higher and higher.

Sgiathalaich

Djeser, those are the things I have been experiecing even with earlier upgrades. That is what is so confusing with these problems with Vue. I did get the eon errors but it is so hard to reproduce at the time and be able to give e-on a step by step answer when you pot at tech support and they ask you to duplicate it. I was able to get them to duplicate one error but not the one you and I are having. :)

ïÏøçö

Djeser,
I think the best thing to do in your case would be to write down when you see the GDI objects go up (what you do when they do) and send that to e-on via the thread. It's entirely possible that the bug is in more places than the ones we know about (mouse movement, mouse clicks in OpenGL) and that is causing your havoc. It might be something that was introduced in this latest version. Remember it said, "New Memory Management Strategy" Well that strategy may still have some ironing out to go.

As to the previous version, perhaps you should start a thread here on how to go back. If you don't have a backup from the previous version, maybe Guitta or one of the Vue experts can tell you how to safely reinstall it and then just upgrade to the last known version that worked for you. I have never tried reinstalling it, so I would not want to give specific advice that could possibly cause you more harm than good. Would be better to leave it to someone who had done it.

Iloco,
It may all be tied into the same type of bug. We'll have to see when they get it working whether that is the case or not. I have noticed that the latest version does seem more skittish than the previous ones.

Just now was playing in Vue Pro and got an eon error. It is as Djeser has said. It gets really slow before crashing with the eon error message, and as you can see with image there are only a tree and terrian added to basic setup. sorry for large image but wanted you to be able to see pologons and objects that are involved wwith this simple scene.

ïÏøçö

Forgot to mention that the GDI Object handle was only at 297 so that may or may not had anything to do with the error and crash. :o)

ïÏøçö

Not sure what's causing that, but I found another bug. If I take a sea weed plant. If I copy it and then do a paste about 12 times (in OpenGL) it crashes with a VuePro.eon error requester. This one is duplicatable.

I couldn't get it to crash at 2 mil polys in OpenGL or even slow down, so I'm not sure what is causing that. When I tried to open a terrain that was 2048x2048, it got very slow, but that was at 8 million polys. Turning off the background draw and other option under OpenGL seemed to speed things up a bit. Do you and Djeser share the same video card? Not saying it's the video card, but perhaps it's some setting that you two have shared that is causing the slowdowns. The crash is probably more likely something in Eon's code. You are right Iloco, it's not the same resource leak issue if it's not getting up to the magic number.

ShadowWind

I think there are still more than one bugs that are causing some problems. At lest by getting rid of them one at a time that is progress. My Video card is an older one but has been working ok with OpenGL. It is a Nividia GeForce2 MX 100/200, 64 mb's memory with latest drivers from Nividia.

ïÏøçö

I bought mine last Sept, it's NVidia GEForce FX something, works fine, but OpenGL is slow for me so I turn it off and just use wireframe. I started in Bryce, so I'm used to wireframe, doesn't bother me.

Sgiathalaich

Please send all details to technical support through our online system. A couple of items to consider (what do I know, Im only a sales guy ;-)) -- -iloco, Ive heard that the nvidia GeForce2 MX was very problematic some time ago. It shipped with very flakey drivers, and, while I think Nvidia polished them somewhat Im not very confident with that card. -Is that spruce tree one of ours? You have 39 objects listed there on the screen and its a grouped item. -If a "crash screen" came up after that VC++ error message, you should include its contents in your support request. -What are those two items in your system tray? Sometimes in-resident utilities and, occassionally a bum driver that came with hardware can cause problems which seem unrelated. Best regards, Lynn Fredricks e-on software

Ok I am really confused now. What was the use for the forum at e-on if we are still required to send each issue to tech support. Seems to me it would be useless when we have this one ar RR and other forum if we just want to discuss among ourselves. That tree was one I was playing with that was gave to me. It is not a Vue tree. Those two items in my task bar are the only two things I run on startup and they are my AVg virus scan and My ZoneAlarm firewall. Those have never given any problems with any of my other 3D applications I use on my computer. Bryce, Poser 5 to name a couple. I had a new ATI Viedo card and it gave me more problems than the Nivida I am using now. If Djester had been using the same as I and we were both having the problem then I could see maybe it being a Nividia issue. Since she wasn't and is using a later card I can not see it being a card issue. I did not get a crash screen after the eon error. I had to close out of Vue and restart it to get back into it. Sometimes I have to a complete reboot of my computer when Vue crash's. Not on the above error.

ïÏøçö

The forum is for collective answers, but sending a message through the additional support button may prioritize a response. There is a risk that you've jumped to unsafe conclusions about your crashing problem. If you want to try to sort it all out here, go right ahead, but it may be faster to get help from support. Best regards, Lynn Fredricks e-on software

Lynn I may be wrong but I think the sorting out is ok here but the fixing is up to e-on. I think there are some programmers that are not employed by e-on that do understand a lot of what is happening when we discuss these problems and they have an idea of what is happening and are just sugessting what it may take to fix the problem. If you are saying the vue forum will not be a high priorty for tech to read the post and problems then I don't see the forum as being used for any useful purpose since Renderosity and most all the 3D graphic sites have a discussion forum about the problems some people are having with Vue Pro. I would like to see an answer to the confusion that is being created now answered so we do know what and how to get our problems solved. No one in the Vue Forum had gave a reply back to any of the post in the last couple of days. Will it always be that slow for a responce. I guess I have been put on the ignore list but I think its e-ons priorty to not keep customers in the dark with their problems. :o)

ïÏøçö

I think an important thing for E-on software to realize that is that a person like myself who is potential user of Vue in the future, may have second thoughts about because of error like this.

As a person in development as profession, issue like this are always on top priority.

As for myself (under another alias, of course!), all my exchanges with the e-on team has just purely dissapeared from the support on the official e-on/Vue site. Funny, isn't it? (No, you won't get more info!) TJ - saddened

Lynn,
Some of these are bugs that have been in it from the offset, bugs missed by your alpha and beta testing teams, since the first release. Do you not think that they have been mentioned to tech support directly? Did they get resolved? No, which means that we should either eat $300-400 or find a solution ourselves. We decided to do the latter and through that collaboration, found a scenario that was too exact to ignore in the one case. SO after 6 months, we finally got some degree of comfort that at least that might be fixed, which will help a lot of us.

I am unclear on "unsafe conclusions?" To what does this refer exactly? The only conclusion we've come to so far in these discussions as that we'd better be able to find a duplicating scenario or we will be set aside, and if we keep up, labeled as trouble makers. If someone at e-on would like to address these problems and work through the bugs in a productive manner, we wouldn't have these conversations, but none of us like to get humored and then told to go away until you can find solid evidence.

ShadowWind

iloco and ShadowWind, its probably helpful to share experiences to see if you are both experiencing the same problems since that does help to narrow down the possibility of what might be causing a particular issue. However, it can also generate a false positive if you've overlooked something that may or may not be present on your systems. It could be something that can appear very minor, or, may not even be recognized by a particular vendor as a problem (for example, with system components that Vue Pro makes use of). The development team has put out a few updates since we shipped Vue 4 Pro, so issues are being addressed. But problems cannot be fixed if the development team cannot duplicate them -- which is why Ive been saying to provide them with as much information as possible. If they cannot duplicate it then, and noone bothers to follow up, they move on to another issue they can duplicate and fix. If I thought you were troublemakers, I would have just ignored your posts. Dont read into my posts anything more than I write in a literal sense. Best regards, Lynn Fredricks e-on software

Lynn its awful hard to be able to stand on both sides of the fence at the same time. I understand what you are saying. I also hope you see what we are trying to say also. What I ment is if tech was to read our post and discussions on an issue is that some people can express themselves better than others and tech might pick up something someone is trying to explain but not in the words tech understands that I may have tryed to say. A good example is Djester was able to explain her problem better than I but it is the same we both are experiencing. ShadowWind has proved his ability to communicate with you in words that I would probly sound offensive had it been me trying to say the exact same thing. So I guess what I am trying to say is I hope tech is listening to all of us and not just the title to a post. I gave up trying to post problems to tech because I am not good at explaing myself as some other people can do. I just sit back and hope someone with same problem post it and tech understands and is able to fix and then I can get the update. It is confusing to try to work with tech when all you get done is answer a question can you duplicate this for us and give us step by step instructions when the next time it is not the same. This can be a nite mare for some users and I fully understand their feelings. Some are intmadated just posting a problem and sit back and hope as I it gets fixed. That is why I am trying my best to not back down untill Vue Pro is the program it was advertised to be. :o) Thanks for not seeing us as trouble makers. We just want a program we can work with and it not give us all the crash's and errors. I can see how Dawn started this thread I hate Vue. It is no fun when you half way through a scene and Vue Pro crash's.

ïÏøçö

Good news guys and gals. I heard from sbell today on e-on's forum and he says that 4.53 will include the GDI fix and a few other fixes. Let's keep our fingers crossed! ShadowWind

There ya go!:-) Lynn