RfE: bring back the Option for disabling the Hardware Acceleration (OpenGL)

opengl
hardware
acceleration

#1

with several users having upgraded to the new version 2017 and not being able to run on their existent systems anymore… pls re-enable the Option “…\Preferences\OpenGL\Use Hardware Acceleration” for disabling on affected systems as in SU 2016 (and older) again.


Pro 2017 crashes when I try to print
#2

I would rather think that the CHECKUP program should be run by all persons wanting to install the new version before the actual install. Either bundle it as part of the installer or, as a requirement for the install, the log file created by the program is required before SU 2017 will install.

This will save a lot of people a lot of wondering and headaches methinks. If there are any problems later then we know it isn’t related to anything tested by CHECKUP.

So far it seems like the new render pipeline is worth it, if it still supports software rendering is another matter. I think not, else the option would have been left in, not so?


#3

So in other words, you want to go back to the old graphics pipeline?


#4

I think the point @sketch3d_de is making is that suddenly a large percentage of slightly older computers are being disqualified from any sort of upgrade.
In the past you could run on a 32bit system if things didn’t work properly, or you could effectively disable opengl and get it to work, albeit slowly.
Now you either have a 64bit computer with an appropriate graphic card or you have nothing.


#5

I understand. At some point those changes are inevitable. How do you make the migration away from these old things?They could make announcements about an upcoming change but there’d still be a lot of people who would either ignore or not get the message. We saw that (and we’re still seeing it) with users of SU2013 and earlier who finding out that Get Location and access to the 3D Warehouse don’t work anymore for those old versions.


#6

I agree, but that doesn’t mean there won’t be a backlash from disgruntled users. No doubt Make users.


#7

True.


#8

I don’t recall many people making a fuss when they dropped 32bit support for mac 3 or 4 versions back…

it should however do an automatic version check as part of check for update…

john


#9

[quote=“DaveR, post:3, topic:33593, full:true”]So in other words, you want to go back to the old graphics pipeline?
[/quote]

no, I (and surely many users w/ non-workstation systems) would prefer, that a software rendering by the operating system (on the CPU) would be feasible instead of having nada.

An user does get crashes launching SU2017 with a intel Core i5-4310U ‘Haswell’ (2014) w/ an intel Graphics 4400… really?

Are there any exact specs which OpenGL functionality needs to be supported or better a list of compatible GPUs?


#10

in our case paying pro users being not amused.


#11

shouldn’t mask the generated ZIP as a LOG file and add the whole Windows system information log into… privacy, ya know.


#12

I can believe it, but I know there will be many many non payers complaining.
Generally if you can afford the software you are more likely to have newer hardware.
A large proportion of the massive audience throughout south east asia, china, the middle east etc won’t have hardware that supports the new system for now.
They will have issues.
You can look at that in several ways.


#13

Software rendering was dropped.


#14

Not arguing with the basic contention here (that the enforcement of OpenGL requirements in SU 2017 and dropping of software mode has abandoned a possibly significant number of users), but I must assume that this restriction was created for some valid technical and business reasons, not simply out of unconcern for users, arrogance, mean-spiritedness or laziness.

Unless you are an OpenGL programmer with access to the SketchUp source code, how do you know what obstacles there might be to continuing the CPU-based rendering option? Maybe this option forces things to be done in a least-common-denominator mode that holds back the Hardware Accelerated version too? Maybe it more than doubles the programming and support effort required? Maybe Trimble sees the potential loss of some customers as costing them less than it would to continue developing the two-mode graphics pipeline?

I write this as a Mac user who has watched for years as unnecessary inconsistencies between the Mac and Windows SU GUIs have languished untouched - likely for the same reason: bad return on investment for the programming effort. Those pleading for a Linux release are in the same boat.


#15

software rendering is processed in the context of Windows not SU, but probably doesn’t provide the advanced OGL graphics feature set (e.g. depth peel transparency etc.) SU 2017 requires.


#16

Wow, has the “Disable Hardware Acceleration” feature been removed from the new version? I used that feature frequently. :frowning: My computer is very slow and producing video animations with Hardware Acceleration turned on, for example, makes the model shadows a real mess.

I normally turn it off when there’s a detailed model animation required. I also turn it off when I have problems with blueprints in LayOut (complex models with HA turned on get glitched and show all lines regardless of the chosen style).

I do realize that a more powerful computer will minimize these problems but what do we do now?


#17

besides of this the OGL check processed during the launch of SU shouldn’t crash… and the checkup tool reports wrong values for the avail. VRAM w/ Radeon cards.


#18

to take the 3D gaming industry as an example, they try to avoid loosing customers with graphics cards not being on-par with recent models by allowing a configuration of the feature set used for the accelerated display output (e.g. anti-aliasing, transparency, shadow etc.) sothat even whith a limited graphics performance an use of the software without all or only parts of the eye-candy is at least possible.


#19

better embed the ol’ graphics pipeline too and switch to it if HA is disabled.