LDraw.org Discussion Forums
LDView 4.2 Beta 1 Released - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: LDView 4.2 Beta 1 Released (/thread-4278.html)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12


Re: LDView 4.2 Beta 1 Released - Steffen - 2012-04-23

Hi Travis,

I have just spotted a little but annoying glitch while doing some more testing:

The preference set "Thumbnails" is not visible in the LDView application
until the first time a thumbnail generator was run.

This leads to an ugly behaviour a user (using LDView the first time and wanting to see thumbnails) has to do:

1. He first needs to let the thumbnail generator run on some folder,
creating images he does not want (as he wants to change the default configuration).

2. Then he needs to fire up LDView and change the preference set. While doing that, he needs to be aware which one to pick: is he using a 32bit Windows explorer, then he needs to run LDView.exe, is he using a 64bit Windows explorer, then he needs to run LDView64.exe

3. Inside the application, he needs to change the "Thumbnails" preference set.

4. Then he can go back to the folder where he wants to see the thumbnail renderings. He there needs to touch all files which from step 1. got an ugly image. This will trigger its thumbnail re-generation.

I suggest to heal this annoyance as follows:

(A) Make the "Thumbnails" preference set present by default always.

(B) Add a checkbox to it whether LDView shall render thumbnails in Windows explorer or not.
Currently, this can only be toggled at install time. I suggest copying the necessary DLLs always,
and letting this checkbox turn their usage on and off (i.e., setting/unsetting the necessary registry key(s)).

© Share the preference sets, especially "Thumbnails" between the 64bit and 32bit instances LDView.exe and LDView64.exe.
TODO: I don't know if this is already the case. I suspect that my Win32-Explorer spawns a Win32-LDView.exe, and that one sees its own copy, whereas I when using the tool interactively, fire up LDView64.exe. These two should share their preference sets.

(D) Change the default settings of the "Thumbnails" preference set.
It currently creates a black background, which looks terrible and frightening in the otherwise "bright" Windows 7 explorer.
I have to always change that manually to "white".
Second: the default field of view setting is terrible, the thumbnails all have a fisheye effect.
My suggestions for (IMHO) better defaults of the "Thumbnails" preference set are:
- background color RGB 245/245/245
- default color RGB 225/225/225
- field of view = 10


Re: LDView 4.2 Beta 1 Released - Travis Cobbs - 2012-04-23

Steffen Wrote:1. He first needs to let the thumbnail generator run on some folder,
creating images he does not want (as he wants to change the default configuration).

I'll update the installer to create the Thumbnails preference set when the corresponding check box is checked in the installer to use LDView to generate thumbnails.


Steffen Wrote:2. Then he needs to fire up LDView and change the preference set. While doing that, he needs to be aware which one to pick: is he using a 32bit Windows explorer, then he needs to run LDView.exe, is he using a 64bit Windows explorer, then he needs to run LDView64.exe

Once I fix the thumbnailer, there should only be one LDView installed. Having said that, both the 32-bit and 64-bit versions of LDView store their preferences in the same place in the registry, so it really doesn't matter which is run.

Steffen Wrote:3. Inside the application, he needs to change the "Thumbnails" preference set.

This will be necessary no matter what.

Steffen Wrote:4. Then he can go back to the folder where he wants to see the thumbnail renderings. He there needs to touch all files which from step 1. got an ugly image. This will trigger its thumbnail re-generation.

Fixing the installer fixes this. However, starting with Windows Vista, MS made it totally ridiculous to force regeneration of thumbnails, and there's not really anything I can do about that.

Steffen Wrote:(B) Add a checkbox to it whether LDView shall render thumbnails in Windows explorer or not.
Currently, this can only be toggled at install time. I suggest copying the necessary DLLs always,
and letting this checkbox turn their usage on and off (i.e., setting/unsetting the necessary registry key(s)).

I'll have to think about that. I can acknowledge the utility, but it's not possible to modify system registry keys (which the Thumbnailer uses) from an app when UAC is enabled. Working around this is a big enough undertaking that I may not ever do so, and not doing it just confuses novice users. Plus, I feel that UAC should be enabled, and that doing anything to discourage this is bad.

Steffen Wrote:© Share the preference sets, especially "Thumbnails" between the 64bit and 32bit instances LDView.exe and LDView64.exe.
TODO: I don't know if this is already the case. I suspect that my Win32-Explorer spawns a Win32-LDView.exe, and that one sees its own copy, whereas I when using the tool interactively, fire up LDView64.exe. These two should share their preference sets.

All LDView settings have always been shared between the 32-bit and 64-bit versions of the app.

Steffen Wrote:(D) Change the default settings of the "Thumbnails" preference set.
It currently creates a black background, which looks terrible and frightening in the otherwise "bright" Windows 7 explorer.
I have to always change that manually to "white".
Second: the default field of view setting is terrible, the thumbnails all have a fisheye effect.
My suggestions for (IMHO) better defaults of the "Thumbnails" preference set are:
- background color RGB 245/245/245
- default color RGB 225/225/225
- field of view = 10

I'll make sure that the default one that I install is more reasonable. The down side of this is that this may clobber any user settings, so I may only set the background color. (I'll have to read my installer docs to see if I can have it only set a registry value when that value isn't yet present.)


Re: LDView 4.2 Beta 1 Released - Steffen - 2012-04-23

many thanks, Travis, for your detailed answer!

the last question can easily be answered:
a "Thumbnails" preset should never clobber an existing one,
only on "fresh" creation.

meanwhile I've played a little more with the thumbnails,
and all the white/grey from my previous posting burns my eyes now...
I've resorted back to the thumbnails settings I had used on the previous system:
bgcolor = rgb(251/250/230)
default = rgb(211/211/211)


Re: LDView 4.2 Beta 1 Released - Steffen - 2012-04-23

ugh, just discovered one more thing
(I've just been migrating to a fresh computer):

The "Thumbnails" preset does not seem to take the "additional folders" setting
into account which you can setup in LDView GUI.
For example, I have a special folder with LSYNTH primitives.
To render the thumbnails correctly, access to this folder needs to be established in LDView.
However, even though I've added that folder in the LDView GUI, the thumbnails
generator doesn't seem to take it into account.
I now remember that I tricked it into it on the old system by manually editing the registry.


Re: LDView 4.2 Beta 1 Released - Travis Cobbs - 2012-04-23

The "extra dirs" settings aren't pref-set specific, but they're supposed to work for all pref sets in all situations. If they're not working for thumbnails, they're probably not working for command line image generation either. That's actually one of the bugs on the list of 4.2 Beta 1 fixes:

Quote:Fixed command line snapshot generation to pay attention to the Extra Search Directories set via the UI.

(Thumbnails use command line snapshots.)

Are you sure that the LDView.exe you have is the 4.2 Beta 1 version, and not an older version? Note also that the thumbnailer uses the most recently run LDView executable. So even if you install 4.2 Beta 1 and then simply run LDView 4.1 from some other location, the snapshots will be generated using 4.1.


Re: LDView 4.2 Beta 1 Released - Steffen - 2012-04-23

I've now looked that up in the registry of the old system.
There, my registry tweaking was this:
Code:
[HKEY_CURRENT_USER\Software\Travis Cobbs\LDView\ExtraSearchDirs]
"Dir001"="C:\\some\\cool\path\\LSYNTH"

[HKEY_CURRENT_USER\Software\Travis Cobbs\LDView\Sessions\Thumbnails\ExtraSearchDirs]
"Dir001"="C:\\some\\cool\path\\LSYNTH"

[HKEY_CURRENT_USER\Software\Travis Cobbs\LDView Screen Saver\ExtraSearchDirs]
"Dir001"="C:\\some\\cool\path\\LSYNTH"
, and it worked.

I've verified that I'm running LDView 4.2 beta 1 of Apr 7, 2012 on the new system.
There, the mentioned registry keys are not present,
and using the GUI to setup additional pathes only affects the "normal" LDView,
but not the thumbnails instance or the screensaver instance.

EDIT:
I think the thumbnailer should use the LDView executable which lies next to it in its directory.
This is the behaviour I would expect. As only 1 DLL can be registered, so can only 1 executable
that does the work. And the one that does it should be the one next to the registered DLL,
not some other one sitting somewhere else on the HD (IMHO).


Re: LDView 4.2 Beta 1 Released - Travis Cobbs - 2012-04-24

The ExtraSearchDirs information is not supposed to be preference set-specific. After a quick scan of my source code, I can't see anywhere that it would be preference set-specific, so I'll have to use the debugger to figure out what is going on.

Every time you run LDView, it sets the following two registry values:
  • HKEY_CURRENT_USER\Software\Travis Cobbs\LDView\InstallPath
  • HKEY_CURRENT_USER\Software\Travis Cobbs\LDView\InstallPath 4.1

The thumbnailer looks up the second one first, and if that isn't found, it looks up the first one. If one of them is found, it then appends LDView.exe to the path, and uses that as the path to the LDView executable. (Note: there is a good reason why there are two registry values, but I'm not going to go into it here, and it's not related to the issue at hand.)

I can see how using the path to the thumbnail DLL would be better, and I'll consider updating it to do that.


errors in 8464.mpd - Steffen - 2012-04-25

I've just discovered more glitches in the file 8464.mpd which you supply with LDView:
- 2 missing axles plus bushes
- miscolorings (dark grey)
- 2 misplaced hydraulic cylinders
- missing file 2996.dat
I also added 2 "Needs Work" notes for the remaining errors I spotted.

Please find the updated file attached to this post.


Re: LDView 4.2 Beta 1 Released - Steffen - 2012-04-25

POVRay documentation on gamma:
http://wiki.povray.org/content/Documentation:Tutorial_Section_3.3#Gamma_Handling
It is especially important to do a test render on your own hardware of file
scenes/gamma/gamma_showcase.pov
, coming with POVRay.
The images within the documentation are just for illustration.

However, the above documentation seems to have been written for pre-3.7 versions :-(

For me now, with POVRay 3.7, playing around a lot, it has proven best to use
Code:
#version 3.7;
global_settings { assumed_gamma 2.2 }
at the beginning of my LDView-output-POV files.

However, I do not know how an older POVRay version (e.g. 3.5) will react on the
#version 3.7;
directive, it could reject the file as "too new for me".
Writing something like this
Code:
#if (version >= 3.7)
   #version 3.7;
   global_settings { assumed_gamma 2.2 }
#else
   // put something else here?, e.g.
#end
is impossible, because version 3.7 will complain about that the #version statement is not the first.

Thus, I think the only way to satisfy both users of older and newer POVRay versions,
the output of both version and gamma number should be made optional, and user configurable,
like the other settings (e.g. reflection amount etc. pp.)


Re: LDView 4.2 Beta 1 Released - Steffen - 2012-04-25

Travis, I'd like to drop a request here again, for something which I missed long already,
but have become so used to it that I nearly forgot it:

when in viewmode "examination",
there's keyboard control for the camera with left/right/up/down keys.

However, there seems to be no keyboard key for zooming in and out.
I would love to see the "+" and "-" keys assigned for this purpose.