Curious all that works fine for me!
Have you a little video of this ?

Of course not. ;-)

If no one else is able to reproduce this, I'll try at work tomorrow and thus determine that my home PC truly sucks.

Look at MoI-options-snaps and read the numbers there.

Hi Mike, I can't seem to repeat anything like what you are describing over here.

Can you repeat this problem when loading in a saved 3DM file instead of only just drawing a new curve? If so then if you could post a 3DM file where you do see it, that would be an easier thing for me to test with over here rather than just drawing random curves because maybe you have some tendency to draw a particular shape of curve that is more likely to trigger the problem or something like that.

Do you have other objects in the model like solids that the curves may be behind?

You say it only happens to you with a full screen view and not in split view? What method are you using to switch between views, any kind of script or just the view tab buttons on the bottom command bar?



> Also, there seems to be a little lag time when I try to move control points over the previous version.
> Also a lag when I am using box selection. The box is somewhat behind in catching up to the cursor.

Do these also persist if you set DisplayThreadLimit=1 ?

- Michael

Hi Mike, my guess is probably what happened with the new version is that you have adjusted some driver settings for it and turned anti-aliasing on. When anti-aliasing is forced on at the driver level it will entirely mess up MoI's selection mechanism.

You probably have some app-specific settings for each different MoI.exe, or an app-specific setting that is only getting applied to the new one and not the old one.

Try going in and removing all special video driver settings for the new MoI.exe, especially anything related to forcing anti-aliasing on and then likely your problem will go away at that point.

- Michael

Wonderful... :-/

I checked my vid settings and there are not specific applications set up to run special 3d setting cases.
My Snap settings are set to factory default.
I do know that this is NOT happening in a parallel opened version of Apr beta. (or so I thought - it is more based on the physical arrangement in the display... see below the pics).

http://www.k4icy.50webs.com/tutorials/selection_test_01.3dm
Here is my test file, but from the sounds of it, anything out of the ordinary is only happening to me... "I saw it, it took a bite out of my boat" he says. ;-)






This strange selectivity changes with the scale at which I zoom in and out.


I took further measures to rule in/out the anti-aliasing setting in the Invidia setup.
(NVIDIA GeForce4 Ti 4800 SE)

With anti-aliasing turned completely off, selection works fine!

--you have to re-load MoI after changing--
With it set to something called 2xQ, I am NOT ABLE TO SELECT ANYTHING!
Something called "4x" is its highest setting, this is where I was currently set at.

I am able to achieve this 'selectivity' with the older version too.

By the way, it all seems to work fine when the anti-aliasing option for the Invidia card is set to "Application Controlled".
Which means that there is no card-forced anti-aliasing to the operation of MoI.

(the above pics are kinds moot now)

Thanks for the quick advice Michael... Knock on wood, I think this may be it.

I changed these settings to "default 'Quality' " when I was messing with it the other night. It changed it to "4x" anti-aliasing from "Application Controlled"

Since I can control this effect that I was experiencing by changing these setting, we must assume that this was the issue.

The other two issues with the lagging seems to have cleared up too.

:-) Whew! (for now)

Hi Mike that's great, so from what I understand you're all set now with the driver anti-aliasing setting put on "application controlled" which probably was originally the default, before you must have done a few tweaks to see if things like "threaded optimization" would help with performance, is that correct?

So it sounds like you are all back in working order now?

And yes, if antialiasing is forced on at the driver level it will definitely mess up MoI's selection mechanism, it basically ends up anti-aliasing and therefore mutating some selection data. With it back to the default "application controlled" you should be back in action now.

Also having antialiasing turned on makes the card do quite a bit of extra work so with an older card that's also not unusual that it would have some performance penalty along with that as well.

- Michael

Great! it works on the mac too!!

Hi Ed, do you see a noticeable improvement on your Mac?

You can get some actual numbers by setting up the following on a shortcut key, then pressing that will show the redraw time in the upper-left corner of the viewport window:
script: /* Toggle redraw time display */ moi.ui.showViewportDisplayTime = !moi.ui.showViewportDisplayTime;

Then with an actual number on the old one and a new number it's easier to tell exactly how much improvement there has been.

Also, what kind of CPU and video card do you have on your Mac?

- Michael

Drew a sphere (mesh angle 5 degrees), Array grid/cube 10x10x10 (1000).
Centered in view and rotated.

My home PC took is 1060 ms average per redraw frame.
That was over the 2000 ms it took with the older version.

Come to work using my newer card:
70 ms redraw! (mesh angle 5 degrees)
162 ms redraw (mesh angle 1 degrees)

I still have to look into what it already splitting up the threads with MoI.

Same objects.
The screen capture on the LEFT is from the April beta, the one to the left is from the July beta.

I have a few curve objects nested within each other, I noticed that there are flickering (or shimmering) patterns that change as you do anything from highlighting different objects to hovering over buttons.
The view image is unchanging and consistent in the April beta. Same .ini file, same graphic.
It's as if there is some random variation in the opacity of the anti-aliased fringes, and it appears to change as the viewport is refreshed.
But since the previous version does not have this effect, then it has something to do with the way MoI's multi-thread thing works.

NOTE: this does not happen when the DisplayThreadLimit=1

Michael, BTW, my NVIDIA GeForece GTX 560 has had it's driver updated to the newest release.
On a slightly related note, the strange behavior with the thread distribution I was dealing with since the released is the same today.

For now, It may be best to leave the DisplayThreadLimit set to 1, which Win still shows that at least four cores are still sharing a % the load.
The speed wasn't increased to much of a noticeable level anyways. Though, in my case, it looks like I'm already enjoying some type of multi-thread emulation in the first place.
It might have something to do with the PC's Hyper-Threading.
If that's the case, then I must be enjoying the advantage to the Hyper-Threading (in my experience with it so far) is that I've had a very stable system that rarely crashes or locks up as I'm in full-boar operation with Photoshop, Corel a software RIP processor and the myriad of other things that are going on. Unlike this work PC's predecessor that crashed all the time, I have to remember to reboot every few days just to clear Photoshop and Corel's heads. ;-)

I post this just for curiosity's sake with this beta release.

So with my card on my particular system, I get some kind of random inconsistency with anti-aliasing rendering when MoI is set to use more than one thread.
I would have to be the 'odd-ball' with the system that exhibits the strange behavior.

Didn't one guy complain of "shimmering" triangles?

Hi Mike, are those objects all stacked up exactly on top of one another?

If so then that's actually an expected consequence of the new multi-threaded display - it's just fundamental to how it works that there will not be the same ordering of processing as there was with a single thread doing the processing.

Things that are exactly tied for their z depth will end up being dependent on the order that they are drawn as far as which one "wins". That's not really a bug, it's just how the display mechanism works.

If you want to avoid that, the main way to do it would be to move the curves you want to have on top to be at a higher z level than the others - even if it's only by a slight amount that will avoid the "tied result in the depth buffer" type of problem that you are showing here.

Either that or if you want to have exactly-depth-tied things drawn in a specific order setting the DisplayThreadLimit=1 to turn off multi core processing would also do it.

But it's generally to be expected that you will see various kinds of "z fighting" flickering when entities are exactly stacked on top of one another, particularly with surfaces.

It's just a common thing that happens with video card displays in general, see here for more information:
http://en.wikipedia.org/wiki/Z-fighting


> Didn't one guy complain of "shimmering" triangles?

Yeah but I've been discussing that over private messages, and it turns out that it's also happening with v2 so it looks like some kind of video card specific issue, not anything related to the new multi-core processing.

- Michael

Okay, thanks...

...oh yeah, same deal on the home PC.
So we now know that the apparent "z-fighting" artifacts are a welcome byproduct of MoI's new multi-threading.

Like the old Alkaseltzer adds: "...if you see the fizzing, you know it's working!"

Hi Mike, you can also easily get z-fighting artifacts without multi-threading as well, it would just previously happen on overlapping surfaces before and not so much on curves.

In prior versions before multi-threading I'm sure you've probably seen this kind of thing with 2 objects overlapping each other and one of them selected or colored differently than the other:



That's z-fighting right there, without any multithreading needed. Multithreading just throws some extra spice into the mixture, particularly with curves.

Basically z-fighting is a display artifact but one that's a normal part of video card display technology. It is possible to do some things to control it, mostly by having the software automatically pull things forward by a little bit in z to influence the result. But it's a somewhat touchy thing because if you pull forward by too much it then can make things show that you really wanted to have hidden.

- Michael

Thanks Michael,

It's a great visual indicator of co-planar surfaces.

Now it's an added bonus for indicating coincident curves as well! :)

- Michael

;-) Aha!

Hello,

Very nice speed upgrade. I really don't get too wrapped up in numbers, my metric for stuff like this usually is being able to perceive a performance increase without a stopwatch. Great job, thanks.