Win 64 version seems a bit sluggish/buggy.

[achrystie]

I've found a bit of weirdness I'd like to verify in the Win 64 version on Vista 64.
I'm running the following:
Intel Q6600
8GB of RAM
GeForce 9800GT
Plenty of extra HDD space.
Dual monitors, one at 1920 x 1080, the other at 1680 x 1050.

I have the following issues.
1) Viewport and boolean update seems quite sluggish even with only a few primitives, certainly not the "realtime" view as shown in the youtube video(s). I get noticeable hitching in the viewport when I simply rotate the model in any rotation mode and any viewport draw method with only two items in the scene.
2) I seem to get the popup for creating a boolean cluster randomly and have trouble getting the booleans to work/show up in some instances. I added a hyperrod, then a small sphere, no popup. I then tried forcing the hyperrod as primary in a boolean cluster, then added a sphere on top, no popup. I then manually added both to a cluster, and the sphere would not cut or add to the original hyperrod. I then cleared everything and redid the operation, still no luck. Finally I zoomed in a bit and chose "toggle boolean", and that seemed to work. This was most strange because I had already created and cleared a previous set of booleans with a sphere and an ellipsoid in the same session, and had none of these issues.
3) Scaling and moving the object in space is very slow to respond when clicking on the buttons on the bottom bar and dragging left and right or up and down. There's a noticeable lag between clicking and when the objects start to move, and it's difficult to get the scaling right as the slider seems extremely sensitive (or lagging so much I miss something). If I scale an object what seems like just a small amount, it sometimes balloons up to massive size, and then shrinks to minimal size on small mouse movements.

I'm going to test and see how well this runs on my far inferior spec'd mac mini.

[boris]

achrystie,

1. I have something similar I guess, Intel Core i7 2.67GHz, and for me the rotation of simple 2-object boolean is very fluid. Just to compare apples with apples, I'm doing it on a pre-made boolean cluster in the library called boxSphere-a.gbr, I drag it into workspace and size it to about 350 pixels high, then orbit the camera, and it's fluid. When rotating the object, not the camera, the difference is that it uses the current rendering mode (the camera rotation always switches to the fastest 'blueprint' mode - flat color and outlines without anti-aliasing). The default rendering mode, full-shaded with cast shadows, is much slower and I wouldn't call rotation in that mode fluid, maybe only about 5 frames per second. Is the speed on your computer similar to that?

2. I think I don't see any bug in what you describe. The Toggle Booleans switch has to be ON to see the boolean results (when it's OFF all the objects are shown as regular positive objects, their boolean roles ignored). Indeed, with the older more laborious method of creating boolean clusters, where you first drag objects from the library as regular objects, then select them and choose Make Cluster from Selected in the right-click menu, then right-click on them individually and assign their boolean roles - you also need to turn Toggle Booleans ON manually to see the effect (if it was OFF).

The newer method is to select the Bool Tool in the bottom Edit panel and drag any regular object from the library - it immediately becomes a boolean cluster with one primary and Toggle Booleans is turned ON automatically. Then you just drop objects from the BooleanTrims section with their pre-assigned boolean roles and that's it. The Drop Options dialog only appears when you drop an object onto an existing boolean cluster, to add a new primary or trim to it. If you drop a hyperrod from the library and then drop a sphere from the library on top of it, it just thinks you want two regular objects and has no reason to show the Drop Options dialog for booleans. If what you wanted was to use the sphere as a trim on the hyperrod, the shortest sequence would be to select the Bool Tool and drop the hyperrod from the library, which turns it into a boolean cluster right away. Then you can drop the sphere on it and you'll get the Drop Options dialog where you can choose the boolean role for the dropped sphere, for instance Outside Body (subtraction).

3. This can be cured by two things. First, choose the fastest drawing mode - the rightmost of the four icons at the top of the Display Settings tab (second tab). This might be enough by itself, because slow drawing greatly aggravates slider sensitivity - by the time it finishes drawing and samples the slider again, the slider has already moved by a lot. Apart from that, you can control slider sensitivity directly by using Tool Res at the top right of the Edit panel.

[jabbaloo]

I can confirm that the x64 version is sluggish compared to the x86 version (testing the 3.0.1 release for both)

I am running:
- Windows 7 x64
- Intel i7 2.67GHz
- 12 GB Ram
- NVidia GTX 285

In Shaded mode, transformations are fluid with, for example, boxSphere-a.gbr in the x86 version. Using the x64 version, transformations are noticeably choppy. When I'm actually trying to model something, the x64 version is fairly unusable due to the lag, while the x86 version seems fine.

For me the solution is to stick with the x86 version until x64 issues are resolved.

[achrystie]

achrystie,

1. I have something similar I guess, Intel Core i7 2.67GHz, and for me the rotation of simple 2-object boolean is very fluid. Just to compare apples with apples, I'm doing it on a pre-made boolean cluster in the library called boxSphere-a.gbr, I drag it into workspace and size it to about 350 pixels high, then orbit the camera, and it's fluid. When rotating the object, not the camera, the difference is that it uses the current rendering mode (the camera rotation always switches to the fastest 'blueprint' mode - flat color and outlines without anti-aliasing). The default rendering mode, full-shaded with cast shadows, is much slower and I wouldn't call rotation in that mode fluid, maybe only about 5 frames per second. Is the speed on your computer similar to that?

2. I think I don't see any bug in what you describe. The Toggle Booleans switch has to be ON to see the boolean results (when it's OFF all the objects are shown as regular positive objects, their boolean roles ignored). Indeed, with the older more laborious method of creating boolean clusters, where you first drag objects from the library as regular objects, then select them and choose Make Cluster from Selected in the right-click menu, then right-click on them individually and assign their boolean roles - you also need to turn Toggle Booleans ON manually to see the effect (if it was OFF).

The newer method is to select the Bool Tool in the bottom Edit panel and drag any regular object from the library - it immediately becomes a boolean cluster with one primary and Toggle Booleans is turned ON automatically. Then you just drop objects from the BooleanTrims section with their pre-assigned boolean roles and that's it. The Drop Options dialog only appears when you drop an object onto an existing boolean cluster, to add a new primary or trim to it. If you drop a hyperrod from the library and then drop a sphere from the library on top of it, it just thinks you want two regular objects and has no reason to show the Drop Options dialog for booleans. If what you wanted was to use the sphere as a trim on the hyperrod, the shortest sequence would be to select the Bool Tool and drop the hyperrod from the library, which turns it into a boolean cluster right away. Then you can drop the sphere on it and you'll get the Drop Options dialog where you can choose the boolean role for the dropped sphere, for instance Outside Body (subtraction).

3. This can be cured by two things. First, choose the fastest drawing mode - the rightmost of the four icons at the top of the Display Settings tab (second tab). This might be enough by itself, because slow drawing greatly aggravates slider sensitivity - by the time it finishes drawing and samples the slider again, the slider has already moved by a lot. Apart from that, you can control slider sensitivity directly by using Tool Res at the top right of the Edit panel.

1) My Q6600 is only 2.4 GHz, and you didn't mention your video card, but generally speaking, given the simplicity of the models, I'd expect it to be "much faster" than it is. I run Solidworks on a similar machine and it is "leaps and bounds" more responsive with assemblies consisting of 100's of parts and comparatively much more complex geometry on each part.

2) I think I didn't explain correctly. I toggled the boolean off and then back on again and it fixed the problem I had. I honestly don't know what the issue was, as I haven't been able to replicate it. I definitely have a couple workflows that seem to work, but my concern is that there is some sort of flagging issue for this toggle.

3) Thanks for the tips. First off the Quick Line viewport rendering is certainly faster, about what I would expect it to be, but honestly it's unusable to me as I can't see the contour of the surfaces without shading. I'd hope/expect the viewport to update in the other shaded modes at about the speed of the quick line method does for me now.
As far as tool res goes. That was a helpful tip, but now I have to say that there should really be some increment between the first tick (all the way to the left), which doesn't seem to allow reasonable changes with basic mouse movement on my system, and the next tick (second from the left) which seems to make the change increments quite, small such that I have to drag the entire distance of a 1920 pixel 24" monitor, just to get about a 1.8 change in scale. The fourth tick, all the way to the right, makes the change unnoticeable to the human eye for literally MASSIVE motions of the mouse. This is just using the default scale of the standard boolean objects as a starting point. I'm not sure what scale up or down would make that fourth tick of any use.

[John Strieder]

Hello, I have the same problems achrystie has.

1) My two machines are:
1. Intel Core2Duo E8400 2x3 GHz // 4 MB RAM // Geforce 8500 GT // Vista 64-Bit
2. Intel QX6700 Extreme 4x2.66 Ghz // 8 MB RAM // GTX 285 // Vista 64-Bit

Especially on the first Machine it's very depressing that on every action I see the hourglass-mouse icon (the blue rotating circle) for ~one second. On the second machine it's similar, just rotating boolean-parts is more fluid.

2) I have problems with booleans too, but I don't know if it's my misunderstanding of Groboto ... or Groboto ^_^; For example, I create an Ellipsoid and a Cube, make them a Boolean Cluster with the Lasso, and then ... I can't set the Cube to "Outside Body", it's greyed out. There's just "Inside all" and "Primary".
Edit: Okay Solution for this Bool-Prob can be found in this thread: http://www.groboto.com/forums/showthread.php?435-Trimming-is-totally-hit-or-miss-with-me.... ;)

Best Regards,
John

[John Strieder]

Indeed, I've installed the x86-Version, and it's working very fine now. The x64-Version is unuseable, really ...

[boris]

Indeed, there is a big difference in rendering speed between 64bit and 32bit, about 2 times (somewhat more than 2 times in quickline mode, somewhat less than 2 times in fully shaded modes). Funny how I didn't notice such a big difference before - I was always testing the 32bit version on another computer, running 32-bit Vista. It's a much older and slower computer, and certainly the program ran slower there, but not as slow as the difference in hardware would indicate...

Now I tested both on the same Intel Core i7 2.67GHz running 64bit Windows 7, and the difference is apparent. I also found out the reason. The 64bit C++ compiler that comes with Visual Studio 2008 is truly awful. I have a Vector3 class defined and it has a dot product A*B = Ax*Bx + Ay*By + Az*Bz. When I'm using A*B it compiles into code than runs about 5 times slower than when I write it out manually as Ax*Bx + ... How can such a simple thing be so mis-compiled????

In the short run we suggest simply using the 32-bit version on 64-bit Windows, as some members of this forum have done already. Beginning with version 3.0.2 which was released today, we are making the 32-bit and 64-bit installations compatible on the same machine. Just download and run both installers one after the other, you'll get separate shortcuts (Groboto v3 and Groboto v3 (x64)) on the desktop and in the Start menu. This way if you really need the 64-bit version with its unlimited memory access (to mesh an especially complex model or to render a huge image), it's there. Otherwise just use the 32-bit version.

Here are some other useful speed comparison numbers. On either 32bit or 64bit the quickline mode is about 5-6 times faster than shaded mode with no cast shadows, which in turn is 1.5 times faster than shaded mode with cast shadows. The latter is on by default, which is a vestige of Groboto 2 whose main emphasis was creation of pretty 3D graphics, not modeling. Maybe we should change that. At least turning cast shadows off shouldn't be much of a loss when modeling (this is in the same panel where the rendering mode is selected, Display Settings (second tab), the next section down called Shadow Settings).

Another thing that affects rendering speed a lot is the size of the object on the screen. Groboto workmode rendering is pure ray-tracing. It has to be: these days polygons are drawn with screaming speed, but as you reshape the primitives of a boolean cluster dynamically, there is no polygonal description of the resulting shape, so it has to resolve the boolean relationship on the fly for every pixel on the screen. The more pixels, the longer it takes. On the other hand, our ray-tracing is local - if you edit a small piece of a large model, it will be fast.

[John Strieder]

Thanks for the explanation and the Tech Talk :) On the shadows, I thought the same, and actually during modeling those hard shadows sometimes can be confused with geometry ;)

[boris]

achrystie,

We fixed the Tool Res thingy (will have it in 3.0.3 on Windows, very soon). Other than, as you say, the scaling control being too crude, it had a bug where for lower scale settings it would not even react to every 1-pixel move of the mouse. Now it's completely smooth - the change in geometry might be tiny, but you get a change for any movement of the mouse. The slider now has 10 divisions, for scales 1:1, 1:2, 1:4 and so on until 1:1024. The last might seem to be an overkill, and it is in most cases, but sometimes these curved intersecting surfaces are so touchy - a really tiny movement produces a whole new opening or breaks a thin fragile bridge - on these occasions people will appreciate really fine control. We have this unique capability - doing booleans on non-mesh objects in real time, which allows constructing extremely thin, delicate shapes that would just be completely lacerated if these were meshes - so we might as well milk this capability for everything it can deliver.

[boris]

The 64-bit performance problem is now solved. Starting with Windows version 3.0.5 (available today) 64-bit and 32-bit have the same performance. No need to install the 32-bit version anymore on 64-bit machines.

[Enupnion]

The 64-bit version does indeed seem much speedier than the previous release. Thank you! :)

[Mora]

I have only tried 3.0.3, 3.0.4 and 3.0.5 x64 versions, but all three exhibit a random crash on delete and/or undo. Usually it just ends with "Groboto must now close", but this time I managed to get an exception stack.
It usually takes a few draws and undoes to crash the application.

32 bit versions of the above do *not* have the same problem.



************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at QDocumentBase.SetNewUndoOp(QDocumentBase* , basic_string<char\,std::char_traits<char>\,std::allocator<char> >* )
at QGBAction.Event(QGBAction* , GBEvent* )
at Grobot.GBMainWnd.HandleMouseDown(QDocumentBase* doc, QRenderView* view, Control sender, MouseEventArgs e, Boolean noSelect, Boolean trapMouse, Boolean eventBool)
at Grobot.GBMainWnd.GBRFrame_MouseDown(Object sender, MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseDown(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.235 (RTMGDR.030319-2300)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
----------------------------------------
Groboto
Assembly Version: 2.1.147.8
Win32 Version: 3, 0, 0, 0
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/Groboto.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.235 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 built by: RTMRel
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.236 built by: RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
SplashScreen
Assembly Version: 1.0.4130.28762
Win32 Version: 1.0.4130.28762
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/SplashScreen.DLL
----------------------------------------
SharpLibrary
Assembly Version: 2.4.0.2
Win32 Version: 2.4.0.2
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/SharpLibrary.DLL
----------------------------------------
Accessibility
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 built by: RTMRel
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
GrobotDisplayControl2
Assembly Version: 1.0.0.2
Win32 Version: 1, 0, 0, 2
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/GrobotDisplayControl2.DLL
----------------------------------------
SandDock
Assembly Version: 2.4.3.1
Win32 Version: 2.4.3.1
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/SandDock.DLL
----------------------------------------
LineControls
Assembly Version: 1.0.2225.5011
Win32 Version: 1.0.2225.5011
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/LineControls.DLL
----------------------------------------
ToolTipLibrary
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/ToolTipLibrary.DLL
----------------------------------------
ComponentFactory.Krypton.Toolkit
Assembly Version: 2.8.0.0
Win32 Version: 2.8.0.0
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/ComponentFactory.Krypton.Toolkit.DLL
----------------------------------------
System.Design
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 built by: RTMRel
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Design/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Design.dll
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 built by: RTMRel
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
KryptonSandDockRenderer
Assembly Version: 1.0.0.1
Win32 Version: 1.0.0.1
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/KryptonSandDockRenderer.DLL
----------------------------------------
GBInterfaces
Assembly Version: 1.0.4244.39449
Win32 Version: 1, 0, 0, 0
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/GBInterfaces.DLL
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 built by: RTMRel
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
AxInterop.WODAPPUPDATELib.1.0
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/AxInterop.WODAPPUPDATELib.1.0.DLL
----------------------------------------
Interop.WODAPPUPDATELib.1.0
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/Interop.WODAPPUPDATELib.1.0.DLL
----------------------------------------
CustomDialogControls
Assembly Version: 1.0.3037.36950
Win32 Version: 1.0.0.0
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/CustomDialogControls.DLL
----------------------------------------
GBFogControl
Assembly Version: 1.0.3052.23421
Win32 Version: 1.0.0.0
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/GBFogControl.DLL
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 10.0.0.0
Win32 Version: 10.0.30319.1 built by: RTMRel
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
SandDock.Design
Assembly Version: 1.0.0.1
Win32 Version: 1.0.0.1
CodeBase: file:///B:/3D%20Apps/GroBoto/bin/SandDock.Design.DLL
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.1 (RTMRel.030319-0100)
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.


If you are interested I can try to debug it further. I have Visual Studio (C# express) installed on this box and I know enough of both C# and C/C++ to be able to do bug hunting for you.

System specs:

Win7 Pro x64 English (But with very weird keyboard settings)
Phenom x4 9550, 8GB of ram,
very non-standard installation paths.

[boris]

Mora,

Yes, this crash on delete happens from time to time. The problem is we have never been able to create a reproducible sequence of events that leads to it. Maybe what you discovered is reproducible?

[Mora]

The problem appears to me quite consistently.

Steps to reproduce:
1. Fire up GroBoto x64
2. Dismiss the trial reminder
3. Select a bot (I use LatticeSpikes DrawBot)
4. Turn symmetry on (appears to be optional but speeds things up)
5. Draw.
6. Switch to Select, mark something up, delete, Ctrl-Z, Ctrl-Z
7. Switch to Bot, Draw
8. If not crashed goto 6

Usually it takes two or three repeats of the above "loop" to get it to crash. It *always* crashes upon trying to draw a new bot.

I actually just managed to get it to crash with classic "This application has stopped working" within one iteration now.

[Mora]

Confirmed, mirror does not influence the problem.

Actually.. reading the stack trace out loud, it seems like the bot undo function is corrupting the linked list of undoable actions.

[Mora]

Also confirmed for 3.0.6