LDView 4.2 Beta 1 Released

[Travis Cobbs]

It's been an extremely long time in coming, but LDView 4.2 Beta 1 is now available for download from the LDView downloads page here (reload the page if you don't see the Test Release section at the top of the Quick Jump section).

This is a Beta release, which means that I’m hoping to get as much feedback as possible. This also means that it is likely not as stable as a final release, so you probably don’t want to try it out if you absolutely hate using buggy software.

Some notable changes:

• Support for texture maps. Hopefully an official texture mapping extension will be approved by the LSC, and the final 4.2 release will work with the official extension.
  
• Support for blue neutral faces for BFC verification.
  
• Added "Right Side Up" feature, along with "Keep Right Side Up" setting while in fly-through mode.
  
• Quite a lot of bug fixes.
  

Please see the full change history in the ChangeHistory.html file included in the packages.

If you are still using a Windows OS prior to Windows 2000, please let me know. I still have the ability to create a legacy installer, but I have not yet done so for the Beta release. If I don't get any requests, I won't do so for the official release.

If you are still using a version of Mac OS X prior to Snow Leopard, please let me know if the Mac version works for you. Note that it is Intel-only, so it definitely won't work on a PowerPC Mac. If you have one of those and want to run LDView on it, please let me know. I can't make any promises that I will even be able to create a release for you, but given that I know it will be a lot of work, I'm not going to even try unless it's specifically requested.

Please send any bugs, suggestions, or other feedback to [email protected]. As mentioned above, the main reason for this release is to get feedback so that the official release will be as high-quality as possible.

[Travis Cobbs]

I've received a report that the Beta doesn't work on Windows XP. I tested it on one of my home computers with Windows XP, and it worked, but I had an earlier report from someone else of one of the pre-Beta 1 builds also not working on XP. So, I'd like to hear what success or failure others have had running LDView 4.2 Beta 1 on Windows XP.

[Travis Cobbs]

My XP system that works is XP Pro SP 3. However, it's way out of date in the way of software updates, so I'm applying those now. Also, I created a legacy installer (which is designed for Windows systems prior to Windows 2000, but might solve the problem for you also). You can find it here:

http://downloads.sourceforge.net/ldview/...e?download

[Philippe Hurbain]

Confirmed, version 4.2b1 crashes on launch on my XP machine (a SP3 too). Legacy install does work fine !

[Travis Cobbs]

Thank your for the report. The fact that the legacy install works should hopefully help me track down the problem. If not, at least there is a version that works.

Just out of curiosity, do you have any old language DLLs in your LDView program directory?

[Philippe Hurbain]

Maybe. I'll verify tomorrow...

[Steffen]

Hello Travis, I'm also trying out your new version.
I'll collect feedback here in this post.

(a)
What I spotted first is: the file 8464.mpd which you deliver with the program is not self-contained.
It references unofficial file 2996.dat, thus, I received an error message when opening it.
I suggest that you put the inofficial file into the MPD.

(b)
I suggest to give the 2 files "8464.mpd" and "m6459.ldr" better filenames.
The leading "m" is confusing users. Why not simply name them
set_8464.mpd and set_6459.ldr ?

©
Why does the 64bit version install LDViewThumbs.dll?
Shouldn't LDViewThumbs64.dll be enough?
Or is the 32bit instance needed for a 32bit instance of Windows explorer?
Or for the common dialog "File/Open" of 32bit processes?
I had expected to only see the 64bit DLL.

(d)
In the model 8464.mpd, there is a building error at the steering wheel.
Look at the two toothed wheels connecting there, they overlap.

[Travis Cobbs]

Thanks for your feedback.

(a)
What I spotted first is: the file 8464.mpd which you deliver with the program is not self-contained.
It references unofficial file 2996.dat, thus, I received an error message when opening it.
I suggest that you put the inofficial file into the MPD.

This is actually somewhat intentional. With default settings, LDView will automatically download the unofficial 2996.dat. I'll think about including it in the MPD, though. Note that this particular sample model was created by Peter Bartfai, who maintains the Qt Linux port of LDView. I may update both sample models to meet OMR requirements, though.

(b)
I suggest to give the 2 files "8464.mpd" and "m6459.ldr" better filenames.
The leading "m" is confusing users. Why not simply name them
set_8464.mpd and set_6459.ldr ?

If I rename them, it will be with a name that matches OMR requirements.

©
Why does the 64bit version install LDViewThumbs.dll?
Shouldn't LDViewThumbs64.dll be enough?
Or is the 32bit instance needed for a 32bit instance of Windows explorer?
Or for the common dialog "File/Open" of 32bit processes?
I had expected to only see the 64bit DLL.

Yes, it is for any time a 32-bit process shows a system file dialog. The 32-bit installer also installs both DLLs if it is installed on a 64-bit system. This was done in response to a user complaint from the 4.1 LDView in the LDraw All-In-One installer. LDView 4.1 (which is 32-bit only, but has a 64-bit thumbnail DLL) only installs the 64-bit thumbnail DLL on 64-bit systems. A user noted that thumbnails didn't appear in the file dialogs of 32-bit apps (including LDView itself). To be honest, I haven't thouroughly tested that having both DLLs installed actually works, though.

(d)
In the model 8464.mpd, there is a building error at the steering wheel.
Look at the two toothed wheels connecting there, they overlap.

Thanks. I'll pass that on to Peter.

[Steffen]

> This is actually somewhat intentional.

Hmm, I think that a demonstration of the "download unofficial files automagically" feature
is not really necessary.
It is less instructive for newcomers than we might think.
Better simply just clearly document it and provide a completely self-contained MPD.
Just my thoughts.

[Philippe Hurbain]

To make sure, I cleared registry and installed LDView in another folder. Same crash on launch. Fortunately legacy version does work fine (I was missing some features introduced in the more recent beta builds).

[Steffen]

Hello Travis, after installing the new version, my Explorer Thumbnails feature does not work anymore on my Win7/64bit.

I'd like to ask if you could add the involved registry keys to the documentation Help.html, please:

Code:

REGEDIT4

; ---------------------------------------------------------------------------------------------------
; register CLSID FA993BF4-40AF-49C1-BD0B-035A275757C1 for file types .dat, .ldr, .mpd
; ---------------------------------------------------------------------------------------------------

[HKEY_CLASSES_ROOT\.dat\shellex\{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}]
@="{FA993BF4-40AF-49C1-BD0B-035A275757C1}"

[HKEY_CLASSES_ROOT\.ldr\shellex\{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}]
@="{FA993BF4-40AF-49C1-BD0B-035A275757C1}"

[HKEY_CLASSES_ROOT\.mpd\shellex\{BB2E617C-0920-11d1-9A0B-00C04FC2D6C1}]
@="{FA993BF4-40AF-49C1-BD0B-035A275757C1}"

; ---------------------------------------------------------------------------------------------------
; 64bit CLSID --> LDViewThumbs64.dll
; ---------------------------------------------------------------------------------------------------

[HKEY_CLASSES_ROOT\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}]
@="LDViewThumbExtractor Class"

[HKEY_CLASSES_ROOT\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}\InprocServer32]
@="C:\\some\\folder\\name\\LDView\\LDViewThumbs64.dll"
"ThreadingModel"="Apartment"

[HKEY_CLASSES_ROOT\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}\ProgID]
@="LDViewThumbs.LDViewThumbExtractor.1"

[HKEY_CLASSES_ROOT\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}\TypeLib]
@="{9FB564E8-0F22-48FE-859C-372B4A8B1CFB}"

[HKEY_CLASSES_ROOT\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}\VersionIndependentProgID]
@="LDViewThumbs.LDViewThumbExtractor"

; ---------------------------------------------------------------------------------------------------
; 64bit TypeLib --> LDViewThumbs64.dll
; ---------------------------------------------------------------------------------------------------

[HKEY_CLASSES_ROOT\TypeLib\{9FB564E8-0F22-48FE-859C-372B4A8B1CFB}]

[HKEY_CLASSES_ROOT\TypeLib\{9FB564E8-0F22-48FE-859C-372B4A8B1CFB}\1.0]
@="LDViewThumbs 1.0 Type Library"

[HKEY_CLASSES_ROOT\TypeLib\{9FB564E8-0F22-48FE-859C-372B4A8B1CFB}\1.0\0]

[HKEY_CLASSES_ROOT\TypeLib\{9FB564E8-0F22-48FE-859C-372B4A8B1CFB}\1.0\0\win32]
@="C:\\some\\folder\\name\\LDView\\LDViewThumbs64.dll"

[HKEY_CLASSES_ROOT\TypeLib\{9FB564E8-0F22-48FE-859C-372B4A8B1CFB}\1.0\FLAGS]
@="0"

[HKEY_CLASSES_ROOT\TypeLib\{9FB564E8-0F22-48FE-859C-372B4A8B1CFB}\1.0\HELPDIR]
@=""

; ---------------------------------------------------------------------------------------------------
; 32bit CLSID --> LDViewThumbs.dll
; ---------------------------------------------------------------------------------------------------

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}]
@="LDViewThumbExtractor Class"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}\InprocServer32]
@="C:\\some\\folder\\name\\LDView\\LDViewThumbs.dll"
"ThreadingModel"="Apartment"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}\ProgID]
@="LDViewThumbs.LDViewThumbExtractor.1"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}\TypeLib]
@="{9FB564E8-0F22-48FE-859C-372B4A8B1CFB}"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{FA993BF4-40AF-49C1-BD0B-035A275757C1}\VersionIndependentProgID]
@="LDViewThumbs.LDViewThumbExtractor"

; ---------------------------------------------------------------------------------------------------
; 32bit TypeLib --> LDViewThumbs.dll
; ---------------------------------------------------------------------------------------------------

; [HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\...]
; will not be set here, because those settings are automatically replicated from [HKEY_CLASSES_ROOT\TypeLib\...]

; ----------------------------------------------------------
; LDViewThumbs.LDViewThumbExtractor
; ----------------------------------------------------------

[HKEY_CLASSES_ROOT\LDViewThumbs.LDViewThumbExtractor]
@="LDViewThumbExtractor Class"

[HKEY_CLASSES_ROOT\LDViewThumbs.LDViewThumbExtractor\CLSID]
@="{FA993BF4-40AF-49C1-BD0B-035A275757C1}"

[HKEY_CLASSES_ROOT\LDViewThumbs.LDViewThumbExtractor\CurVer]
@="LDViewThumbs.LDViewThumbExtractor.1"

; ----------------------------------------------------------
; LDViewThumbs.LDViewThumbExtractor.1
; ----------------------------------------------------------

[HKEY_CLASSES_ROOT\LDViewThumbs.LDViewThumbExtractor.1]
@="LDViewThumbExtractor Class"

[HKEY_CLASSES_ROOT\LDViewThumbs.LDViewThumbExtractor.1\CLSID]
@="{FA993BF4-40AF-49C1-BD0B-035A275757C1}"

(i)
Did I forget some?

(ii)
I've installed the 64bit version, i.e., LDView64.exe, LDViewThumbs.dll, LDViewThumbs64.dll.
Thus, I don't have LDView.exe. Is maybe LDView.exe missing? Or does LDViewThumbs.dll also use LDView64.exe?

(iii)
Do I have to run some regsvr command or similar to re-register these DLLs?

(iv)
Travis, at the above registry keys dump I spotted that
HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\{9FB564E8-0F22-48FE-859C-372B4A8B1CFB}\1.0\0\win32
points to the 64bit library, although it sits inside the 32bit registry branch.
According to http://msdn.microsoft.com/en-us/library/...s.85).aspx,
this is behaviour by design. But this leads to the effect that 32bit applications get the 64bit DLL this way.
According to http://social.msdn.microsoft.com/Forums/...90dbde68b/
, this can be a problem.



Still, thumbnails do not work here anymore :-(
I reinstalled the 64bit LDView version, and tried running both the
32bit Explorer.exe from C:\Windows\SysWOW64\Explorer.exe
64bit Explorer.exe from C:\Windows\Explorer.exe

Ideas or help, anybody?

[Steffen]

(A)
Travis, I was able to solve the problem:
I had to copy LDView64.exe to LDView.exe.
Then the thumbnails reappeared magically. As the chain of invocation now here is
Explorer.exe (64bit) ------> LDViewThumbs64.dll ------> LDView.exe
, I therefore conclude that LDViewThumbs64.dll erroneously tries to access LDView.exe instead of LDView64.exe.
Do you agree?

(B)
Another problem: 32bit applications (for example, MLCad.exe) do _show_ the thumbnails now,
but they do not _generate_ them. As I have LDViewThumbs.dll sitting around
on my system, I had thought it would spawn LDView64.exe (on 64bit systems), and LDView.exe (on 32bit systems)
to generate them. However, it does not. I have 2 suspicions why it does not work:
- as we saw in (A), LDViewThumbs64.dll does not spawn LDView64.exe, but LDView.exe erroneously, thus, I suspect that LDViewThumbs.dll vice versa tries to spawn LDView64.exe and fails
- or, the problem could get caused by the TypeLib registry setting, which, even for 32bit processes, still points to the 64bit DLL (see above)
As a solution, I suggest that you use separate CLSID and TypeLib identifiers for 32bit and 64bit.
The current re-using of them adds much confusion. Tracing down errors would be much easier that way.

©
Travis, I also spotted a problem with the registry keys where you store the pathes for the additional files
(Dir001, Dir002, Dir003 and so on). Note that all instances of them (in the current configuration, in the
presets, and in the screensaver) are affected:
when you edit their list via the GUI, i.e., you add some and then you remove some,
in the registry relicts remain. For example, my editing in the GUI was to first setup 4 pathes,
then again delete some to just have one. What resulted in the registry was that settings
Dir001, Dir003, Dir004 (but no Dir002) were present.
I think that this can lead to the effect that when a user then again adds a second path via the GUI, this will create a Dir002,
and then after restarting LDView, suddenly 4 pathes will be present, because the gap is closed.
Could you check that code?

[Steffen]

Problem (A) still exists.

Problem (B) was an error on my side. During my many tries, I had hidden file LDViewThumbs.dll erroneously.

Problem © still exists.

[Steffen]

Hello Travis,

POVRay 3.7 or higher will issue a warning when the first statement in a .pov scene is not #version.
Future versions will make that setting mandatory.
This will allow POVRay to parse .pov files of older syntax, according to
http://www.povray.org/documentation/view/3.6.1/240/

Thus I'm asking to extend the .pov file output of LDView
by that first line, stating the POVRay syntax version which the output is in,
so it should probably be, as I assume:
#version 3.5;

I additionally noticed, that from version 3.7 on, each .pov file seems to have to contain a
global_settings { assumed_gamma 2.2 }
(or use a different number) statement as well, otherwise will trigger a warning,
so we should add that statement as well I think...
http://www.povray.org/beta/
http://www.povray.org/documentation/view/3.6.1/260/

- Steffen

[Steffen]

Travis, would it also be possible to increase the maximum zoom level of LDView
from currently 199 to 1000?
I find myself frequently annoyed by that limit,
and just now have found the "hidden" registry key / command line option to raise it to 1000...

[Travis Cobbs]

(A): You are correct. This is a bug that I missed in my testing due to having LDView.exe present. I will fix it.

©: Thanks. I'll fix this.

[Travis Cobbs]

Thanks. I will verify your findings and update accordingly.

[Travis Cobbs]

The default value of 199 is specifically designed to prevent you from ever winding up "inside" the model. Any value above that results in weird rendering artifacts when you zoom in until you're inside. However, since fly-through mode produces the same weird rendering artifacts, there's definitely an argument for having it in the UI. I'll definitely consider it.

[Steffen]

I just figured that the gamma setting probably should become one of the POVRay export options in LDView,
and not hardcoded...

[Steffen]

As always, I greatly appreciate your quick responses in such issues.
LDview is a really, really great piece of software.

[Steffen]

Travis, I've spotted another thing I feel missing:

exported .pov files contain these lines at their beginning:

Code:

#declare LDXQual = 3;    // Quality (0 = Bounding Box; 1 = No Refraction; 2 = Normal; 3 = Stud Logos)
#declare LDXSW = 0.5;    // Seam Width (0 for no seams)
#declare LDXStuds = 1;    // Show studs? (1 = YES; 0 = NO)
#declare LDXRefls = 1;    // Reflections? (1 = YES; 0 = NO)
#declare LDXShads = 1;    // Shadows? (1 = YES; 0 = NO)
#declare LDXFloor = 1;    // Include Floor? (1 = YES; 0 = NO)

But edges can not be turned on and off this easy.
You declare a macro LDXEdges always in that case:

Code:

#declare LDXEdges = union
{
    EdgeLine(<-160,1,48>,<-155,0,48>,EdgeColor)
        ...
}
...
object { LDXEdges }

Note the missing #if around the last object instruction.
I would like to be able to easily turn on and off such edges the same way as the other switches above.
This can easily be achieved by changing the above snippet to:

Code:

#if (LDXEdges > 0)
#declare LDXEdgesObject = union
{
    EdgeLine(<-160,1,48>,<-155,0,48>,EdgeColor)
        ...
}
#end
...
#if (LDXEdges > 0)
   object { LDXEdgesObject }
#end

which I would like much better.
However, that would break existing files which might rely on that the object variable currently is named LDXEdges.
So probably the ideal solution would be to keep the current name LDXEdges for the edges object,
and invent a new name for the boolean toggle.

In case that in LDView's export options edge export is turned off,
the code above should read:

Code:

#if (LDXEdges > 0)
   #ifndef LDXEdgesObject
      #error "This file got exported from LDRAW without edges. Either define your own ones in object LDXEdgesObject, or re-export it from LDView with edges turned on."
   #end
#end
...
#if (LDXEdges > 0)
   object { LDXEdgesObject }
#end

[Travis Cobbs]

I don't plan to do anything if the Edges option isn't checked when the export is made. However, when edges are enabled, there will be a new flag in the list of flags at the top of the POV file: LDXSkipEdges. This flag will only be present if edges are included in the export, and if it is present, LDView itself will always set it to 0.

[Travis Cobbs]

When I looked at this a long time ago, it seemed that there was a lot of disagreement over the appropriateness of including this option in POV files. I seem to remember that the instructions were that the USER should include it on the command line if that's what they wanted. If I add it (which I will only do after my investigation indicates it is be appropriate), I'll definitely make it optional. Depending on what my research turns up, then assuming I decide to add it, I'm not sure if I will make it on by default or off by default, but in addition to its presence in the file being configurable, I'd also make the actual value configurable.

[Steffen]

POVRay 3.7 and up issues a warning if it is _not_ present.

Just make it optional with a checkbox,
and let the user set a value - voila.

It's similar to the rest of the illumination settings.

[Steffen]

yep, nice

[Travis Cobbs]

I did some research, and I discovered that. However, if you look here and search for assumed_gamma, you'll see that it's more complicated than that. Specifically, it interacts with the #version tag in ways that I'm not fully understanding simply by reading what they write. So, if I put 3.5 in #version, it seems that this changes the behavior of assumed_gamma. Also, I think adding #version 3.5 stops the assumed_gamma warning.

It's clear that I need to do something. I'd just like it if all my default values were self-consistent. I'll probably make the #version setting one of the options, perhaps with 3.5 as the default value.

[Steffen]

Yeah, thanks. some of the things are a little confusing to me as well.
I don't quite understand all of the reasoning of the POVRay people.
For example, why require all people to put a gamma instruction into their files?
They could as well have assumed a suitable default (as in the past).
From what I conclude, that default in the past for the PC has been too bright.
Now I assume that they wanted to change that default,
but that would have broken all existing scenes.
This probably led them to require the #version tag,
and through the discussion of introducing it, probably someone came up with
"if we require people to specify the #version, then why not at the same time
require them to specify a gamma?"
To me, this is how it appears that these 2 new future-mandatory settings got introduced.

Yes, I also think that the 2 (#version and gamma) are related in some way. I think if you write
#version 3.5;
, then you get the 3.5 default gamma and no warning, if you write
#version 3.7;
, then you get the 3.7 default gamma and a warning, and probably in future if you write
#version 3.8;
, then you get no default gamma and an error about that it is missing.

I also had thought to suggest to output
#version 3.7;
, but that would have produced a warning when people with POVRay 3.5 or 3.6 open such a file
("the file you're opening is of a newer syntax than your current POVRay version, some features might not work as expected"
and stuff).

To make a long story short: I agree with you that it probably would be the best to give the user
a chance to adjust such things. Of course, LDView outputs .pov file in a certain syntax version,
so it could easily output the #version it creates, but if a user wants to switch that from #version 3.5 to #version 3.7,
then without a GUI control he's lost.
The same goes for the gamma: making the output setting optional, giving it a suitable default, and letting the user
adjust the value if necessary is the best thing you can do here.

Sorry for the long text.



EDIT: I just found these - they shed some light into the issue:

#version
http://news.povray.org/povray.beta-test/...ay.org%3E/

gamma
http://wiki.povray.org/content/HowTo:Fix...mma_system

[Steffen]

Travis, I just noticed that LDView's primitives substitution does not catch
the "tangent" primitives

1-4tang.dat
1-8tang.dat

I feel this being a loss; would it be possible to add that?

[Travis Cobbs]

I'll have to investigate.

As a side note, it also doesn't support the 1-8sphc.dat primitive, but that one is because I know it's going to take a lot of work, and that primitive isn't used a lot.

[Steffen]

yes. supporting the tangents, however, should be quite easy.

[Steffen]

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

[Travis Cobbs]

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.

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.

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

This will be necessary no matter what.

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.

(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.

© 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.

(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.)

[Steffen]

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)

[Steffen]

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.

[Travis Cobbs]

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:

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.

[Steffen]

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).

[Travis Cobbs]

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.

[Steffen]

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.

[Steffen]

POVRay documentation on gamma:
http://wiki.povray.org/content/Documenta...a_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.)

[Steffen]

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.

[Steffen]

I also feel some small thing missing for the cutaway rendering mode:

I currently can only turn it on and off by using CTRL+mousewheel.

This means that for toggling it on and off I will always move the cut plane.
This is something undesired in some situations.
Instead, you want to move the cutting plane to some location,
and then simply turn that mode on and off.
Thus, I'd like to ask for a button in the toolbar,
similar to the one that toggles the cutaway wireframe mode on and off,
which toggles the whole cutaway mode on and off, please.

[Steffen]

Travis, I just noticed that the cutaway plane does not get exported to .pov.
This is a missing screw, as I had used that cutting plane to cut away
obstructing things in the scene (a big house in the front).
As it is trivial to do, I'd like to ask this cutting plane exported to .pov as well, please...
:-))

[Travis Cobbs]

I'm probably not going to add a new function prior to the official 4.2 release, but I'll consider it for a future release. A new function requires a new icon, plus implementing the functionality in all three versions of the program (Windows, Mac, and Qt). I may put in a keyboard-only toggle key prior to the 4.2 release, though.

[Travis Cobbs]

Figuring out the exact location for the cutaway plane may be easier said than done, since in LDView it's in Z-Buffer space. However, please show me a POV snippet to do this, and I'll investigate.

[Travis Cobbs]

I'll try to get it in before the official 4.2 release. I'll probably also add 'W' and 'S' to do the same thing, since that's how fly-through mode works.

[Philippe Hurbain]

I can't find again the option to change highlight color in tree view...???

[Travis Cobbs]

Well, that's odd. I'll have to investigate where that disappeared to and put it back.

[Steffen]

I can see it fine.
It is in the model tree window bottom left.

EDIT: ugh, right, only the checkbox is there. no color choice anymore. that's what you miss, right? indeed, it seems gone.

[Jason Smith]

Working as it should (I think) on Ubuntu 12.04 LTS. 64bit.

EDIT: I'm getting a repeatable crash when trying to print. File/Print, screen dims and LDView crashes away. I tried to generate a bug report but that isn't working with this app.

[Willy Tschager]

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.

(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.)

Just for your information. The AIOI writes the following reg keys:

Code:

Registry.SetValue(HKEY_CURRENT_USER, "Software\\Travis Cobbs\\LDView\\Sessions\\Thumbnails", "_SessionPlaceholder", "DO NOT DELETE.", REG_SZ);
Registry.SetValue(HKEY_CURRENT_USER, "Software\\Travis Cobbs\\LDView\\Sessions\\Thumbnails", "BackgroundColor3", "16777215", REG_DWORD);
Registry.SetValue(HKEY_CURRENT_USER, "Software\\Travis Cobbs\\LDView\\Sessions\\Thumbnails", "Seams", "0", REG_DWORD);
Registry.SetValue(HKEY_CURRENT_USER, "Software\\Travis Cobbs\\LDView\\Sessions\\Thumbnails", "SortTransparent", "0", REG_DWORD);
Registry.SetValue(HKEY_CURRENT_USER, "Software\\Travis Cobbs\\LDView\\Sessions\\Thumbnails", "DrawLightDats", "0", REG_DWORD);
Registry.SetValue(HKEY_CURRENT_USER, "Software\\Travis Cobbs\\LDView\\Sessions\\Thumbnails", "PerformSmoothing", "0", REG_DWORD);
Registry.SetValue(HKEY_CURRENT_USER, "Software\\Travis Cobbs\\LDView\\Sessions\\Thumbnails", "TextureStuds", "0", REG_DWORD);

for LDView's thumbnail generation.

w.