Another cool trick thanks to Wasamonkey ...

[thedaemon]

get a better videocard/system :):shrug:

[markyjerky]

I'm doubtful that it has anything to do with vid card.

Other apps on same video card perform same operation about 10 - 100 times faster.

Bjorn knows about the issue I think. And it has something to do with excessive garbage collection I'm willing to bet.

[thedaemon]

what applications are these?? To my findings wings uses almost every ounce of power my video card can push. I timed it with fps, but I just counted :) its soo much faster than 3ds max, dont know about others.

[markyjerky]

The apps ... Nendo, Anim8or, UltimateUnwrap

My conculsions are drawn with a great deal of care where this particular topic is concerned. I can probably generate a video screen-dump that proves that Wings3D has some specific areas where it's performance could be enhanced by orders of magnitude.

I would encourage the intellectually honest who follow this thread to take Wings3D and TaskInfo2003 on a Win32 machine (if that's your platform) and experimentally determine the affect that smart (or not so smart) high-lighting has on CPU usage.


Wings3D is monitoring something it really should not be ... and looping and trying to dectect something it should be ignoring ... exactly when a high-poly model has been smoothed once or twice and then the user goes to the menus. Bjorn knows about this problem and has recognized it as an area where improvements could be made (to the best of my recollection). And I'm betting that is a few key users with artistic skill, verbal skills, and some logical skills could offer some workarounds, he'd implement them in short order.

If you are not pushing your models to 80,000 polygons (after 1 or two smooths), then you might not experience the problem.

I will upload a model.

http://www.ggaliens.com/temp/batrat31.zip

Smooth it once or twice and then use TaskInfo2003 to see what goes on during menu mouse-over. Actually, you don't have to smooth it to witness the CPU jumping that should not happen. But you do have to smooth it once or twice to get the lag and sluggish menus.

Not all performance issues have to do with video cards. I've got a GeForce II MX a few years old ... but it is more than happy to smooth this model and allow menu play in a bunch of other apps.

[KayosIII]

This has to do with the fundemental of how the program operates in erlang... It will require a lot of work to fix.

[markyjerky]

I'm not sure I buy it KayosIII. What's out of application control ? why can't the application just take control of the mouse over client area messages ? I really bet it can take better control.

Are you telling me Erlang has a rule that says a mouse over client area MUST be passed to some routine that does all the point-in-polygon tests ? I don't think so.


I just want back to do more testing and at least some part of the problem has to do with some extending processing / CPU hits that seem to happen when there is a green object awaiting a state change to red or unselected. Even a low poly object in green state really messed up the cpu, and mostly during menu mouse-over. A state change from green to unselected should be "free" for the application to instantiate when a user clicks on a menu. I would think that somehow there is both a problem and a solution outlined here.

[thedaemon]

why smooth the model 2 times in a modeling app, shouldnt that be left for the final render.

[nervous_twitch]

To ensure that it is smoothing as you expected it to. I do it all the time.

[thedaemon]

I meant why smooth it 2 times and modify the high cage?

[markyjerky]

thedaemon ...

You are trying to get my goat. You can try ... but the bug has been fixed. Bjorn is a good listener ... he wades trough a bit of hysteria to find the nuggets.

(there's nothing in my thread that said you HAD to smooth twice to get the problem. It appears for lower polys. And I never said that if I had smoothed or smoothed twice ... that the subsequent menu operation would be one to change the model).

We need to BOTH praise, and disect Wings3D in these forums.

[KayosIII]

I was commenting on the speed of the smooth operation... You are talking about something different.

[markyjerky]

No prob KayosIII ... I thought you were talking about display lists and the need for those. See, we both misunderstood.

[KayosIII]

Actually I was talking about the way that Wings uses GB_Trees and how this makes smooth painfully slow.

Anyways I looked at the problem described and think that a possible solution would be to multithread the app. This would have the effect of slightly reducing the overall performance of the app but increasing the responsiveness dramatically.
Probably the Menu System and toolbar should have its own thread as should each Window...
This I believe is quite doable in erlang and would have a dramatic performance boost on multiprocessor machines.

Anyways -- just a suggestion.

[Mauritius]

I think the issue with the CPU getting to its knees when Wings tries to highlight a what's under the mouse could be tackled in several ways.
One option would be to draw the view into a buffer of the current screen res and give every polygon a different "color". In a 32 bit deep buffer, you could have a model with over 4 tera polygons.
A LUT would have to be maintained that holds references to the resp polys. The value from the screen under the point where the mouse cursor resides would then allow to quickly draw the resp. polygon in 'selected' state w/o bugging the CPU.

.mm

[wasamonkey]

mauritius
maye im misunderstanding what you are saying
but it sounds like it wouldnt work
when you change the angle it would have to dump that info and make a new ref
also it would have to recalulate what you already seleted if you change angle after you started seleting

if im mis understanding then please say so

[markyjerky]

Mauritius ... I think it's a good idea.

I think Mauritius understood that the trick buffer would have to be repainted with a viewport transformation. I also think the expense of that repaint is well understood compared to some of the other approachs.

I just don't know where "TERA" comes from. 32 bits = 4 billion indexes. Or am I missing something.

Mauritus, make sure you lug this idea over to the development forum if you have not already.


This apporach could "kick in" when models reach a certain polygon level. In order to keep lower-polymodeling super fast.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.