LDView 4.2 Beta 1 Released


LDView 4.2 Beta 1 Released
#1
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 ldview@gmail.com. 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.
Reply
Re: LDView 4.2 Beta 1 Released
#2
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.
Reply
Re: LDView 4.2 Beta 1 Released
#3
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
Reply
Re: LDView 4.2 Beta 1 Released
#4
Confirmed, version 4.2b1 crashes on launch on my XP machine (a SP3 too). Legacy install does work fine !
Reply
Re: LDView 4.2 Beta 1 Released
#5
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?
Reply
Re: LDView 4.2 Beta 1 Released
#6
Maybe. I'll verify tomorrow...
Reply
Re: LDView 4.2 Beta 1 Released
#10
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).
Reply
Re: LDView 4.2 Beta 1 Released
#78
I have some problems with this beta version,too. I'm running WinXP 64-bit and when I start the Ldview64.exe and load a model I don't see any thing. But if I switch to fullscreen I see my model perfectly. I also see it without problems when I turn the toolbar off. In that moment I turn the toolbar on it disappears again.
Reply
Re: LDView 4.2 Beta 1 Released
#79
Yours is the first report of behavior like this, and I'm somewhat at a loss as to how to track down the problem. I do notice that when I toggle the toolbar, the model disappears, but as soon as I do anything after that, it reappears. I'll investigate fixing this, but it doesn't sound like the problem you're seeing. If you click and drag in the blank model area, does the model appear?
Reply
Re: LDView 4.2 Beta 1 Released
#80
If I click in the blank area nothing happens- also the toolbar is cut off after the previous step button when I toggle the toolbar on again. And sometimes when I start LDView with toggled on toolbar I don't see the toolbar itself....
I also can not drag and drop a model file into LDView as long as the toolbar is on- there is no problem when the toolbar is off...

Don't now if this only a problem under WinXP 64 bit?
By the way I have OpenGL 4.2.0
Reply
Re: LDView 4.2 Beta 1 Released
#82
Could you try the 32-bit version? I don't have access to a 64-bit XP machine for testing, and I haven't seen anything like that in Vista or Windows 7.
Reply
Re: LDView 4.2 Beta 1 Released
#84
So I tried the 32-bit version its works all fine- but like other already mentioned only over legacy install

I reported the bug of the 64-bit version so that the stable release of 4.2 don't will have this bug - It's no problem to use until the release of this one the 32 bit version....

Only thought that the 64-bit version could use more than one core (which could maybe an advantage with a i5 quadcore)....
Reply
Re: LDView 4.2 Beta 1 Released
#85
All three versions will use more than one core, but LDView only uses multiple cores for transparency sorting (one extra core) and conditional edge line calculations (as many cores as are available). So, under many circumstances, it won't visibly be using all the cores.

Since I don't have access to a dev machine with XP 64, it's very unlikely I'll be able to track down the source of your problem before the official release, but thank you for reporting it. I really do appreciate all bug reports.
Reply
Re: LDView 4.2 Beta 1 Released
#81
Bit of an open door but: You might be loosing the OpenGL context somehow.
Reply
Re: LDView 4.2 Beta 1 Released
#83
Thanks for the suggestion. I don't think I recreate the OpenGL context when the toolbar is toggled, but I'll have to check my code to be sure. I think I just show/hide the bar windows, and then resize the OpenGL window. (In LDView, the OpenGL window is a borderless sub-window of the main LDView window so that it's out of the way of the optional toolbar and status bar.)
Reply
Re: LDView 4.2 Beta 1 Released
#7
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.
Reply
Re: LDView 4.2 Beta 1 Released
#8
Thanks for your feedback.

Steffen Wrote:(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.

Steffen Wrote:(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.

Steffen Wrote:©
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.

Steffen Wrote:(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.
Reply
Re: LDView 4.2 Beta 1 Released
#9
> 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.
Reply
Re: LDView 4.2 Beta 1 Released
#11
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?
Reply
Re: LDView 4.2 Beta 1 Released
#12
(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?
Reply
Re: LDView 4.2 Beta 1 Released
#13
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.
Reply
Re: LDView 4.2 Beta 1 Released
#16
(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.
Reply
Re: LDView 4.2 Beta 1 Released
#14
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
Reply
Re: LDView 4.2 Beta 1 Released
#17
Thanks. I will verify your findings and update accordingly.
Reply
Re: LDView 4.2 Beta 1 Released
#19
I just figured that the gamma setting probably should become one of the POVRay export options in LDView,
and not hardcoded...
Reply
Re: LDView 4.2 Beta 1 Released
#23
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.
Reply
Re: LDView 4.2 Beta 1 Released
#24
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.
Reply
Re: LDView 4.2 Beta 1 Released
#26
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.
Reply
Re: LDView 4.2 Beta 1 Released
#27
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
Reply
Re: LDView 4.2 Beta 1 Released
#39
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.)
Reply
Re: LDView 4.2 Beta 1 Released
#95
I can't remember why I decided to do this, but for L3P 1.4 beta output I do the following:

Code:
#version 3.7;

global_settings
{
    assumed_gamma    1.0
}

#macro gamma_color_adjust(in_color)
    #local out_gamma = 2.2;
    #local in_color = in_color + <0,0,0,0,0>;
    color rgbft
    <
        pow(in_color.red, out_gamma),
        pow(in_color.green, out_gamma),
        pow(in_color.blue, out_gamma),
        in_color.filter,
        in_color.transmit
    >
#end

// Floor
object
{
    plane { y, 4 hollow }
    texture
    {
        pigment
        {
            checker
            pigment {gamma_color_adjust(<067,084,029>/255)}
            pigment {gamma_color_adjust(<040,066,018>/255)}
        }
        finish { ambient L3Ambient diffuse L3Diffuse }
        translate <1/2,0,1/2>
        scale 640
        translate trans_amount
    }
}

I have to use the gamma_color_adjust macro every time there is a color definition. It is a pain, but it works.
Reply
Re: LDView 4.2 Beta 1 Released
#20
As always, I greatly appreciate your quick responses in such issues.
LDview is a really, really great piece of software.
Reply
Re: LDView 4.2 Beta 1 Released
#15
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...
Reply
Re: LDView 4.2 Beta 1 Released
#18
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.
Reply
Re: LDView 4.2 Beta 1 Released
#21
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
Reply
Re: LDView 4.2 Beta 1 Released
#22
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.
Reply
Re: LDView 4.2 Beta 1 Released
#25
yep, nice
Reply
Re: LDView 4.2 Beta 1 Released
#28
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?
Reply
Re: LDView 4.2 Beta 1 Released
#29
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.
Reply
Re: LDView 4.2 Beta 1 Released
#30
yes. supporting the tangents, however, should be quite easy.
Reply
Re: LDView 4.2 Beta 1 Released
#31
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
Reply
Re: LDView 4.2 Beta 1 Released
#32
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.)
Reply
Re: LDView 4.2 Beta 1 Released
#33
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)
Reply
Re: LDView 4.2 Beta 1 Released
#50
Travis Cobbs Wrote:
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.

Travis Cobbs Wrote:
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.)

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.
LEGO ergo sum
Reply
Re: LDView 4.2 Beta 1 Released
#51
Ah, this explains why maybe nobody has complained yet.

I'm not sure if this is something the AIOI should do.

I think that the LDView installer should take care of everything necessary,
without additional tweaking before or afterwards by the AIOI.
Reply
Re: LDView 4.2 Beta 1 Released
#53
As far as I know, the AIOI does not directly use LDView's installer, but instead reproduces its behavior. This is done because LDView's installer really isn't designed to be packaged inside another.
Reply
Re: LDView 4.2 Beta 1 Released
#55
Steffen Wrote:I think that the LDView installer should take care of everything necessary,
without additional tweaking before or afterwards by the AIOI.

The AIOI doesn't use the LDView installer at all. I prefer let he AIOI handle the single files, reg keys, ... - for the sake of interaction with all the other progs. Only POV-Ray uses its own installer 'cos of the redistributable license.

w.
LEGO ergo sum
Reply
Re: LDView 4.2 Beta 1 Released
#56
ah, understood. thanks for the info.
Reply
Re: LDView 4.2 Beta 1 Released
#52
Thanks for the info. I'm not entirely sure I like all those defaults, but I'm guessing they're that way in order to produce faster rendering, which for thumbnails does make sense.
Reply
Re: LDView 4.2 Beta 1 Released
#54
I don't like those defaults, I better like

Code:
REGEDIT4

[HKEY_CURRENT_USER\Software\Travis Cobbs\LDView\Sessions\Thumbnails]
"_SessionPlaceholder"="DO NOT DELETE."
"FullscreenWidth"=dword:00000280
"FullscreenHeight"=dword:000001e0
"FullscreenDepth"=dword:00000020
"DefaultColor3"=dword:00d3d3d3
"BackgroundColor3"=dword:00fbfae6
"Antialias"=dword:00000000
"LineSmoothing"=dword:00000001
"BFC"=dword:00000000
"ShowHighlightLines"=dword:00000001
"UseQualityLighting"=dword:00000001
"SubduedLighting"=dword:00000001
"UseSpecular"=dword:00000000
"DrawLightDats"=dword:00000000
"PerformSmoothing"=dword:00000000
"TextureStuds"=dword:00000001
"UseQualityStuds"=dword:00000001
"Texmaps"=dword:00000000
"CurveQuality"=dword:00000008
"RandomColors"=dword:00000000
"AllowPrimitiveSubstitution"=dword:00000000
"FOV"="10"
"LightVector"="0.282267,0.288104,0.915053"
"Seams"=dword:00000000
"BlackHighlights"=dword:00000000
"ShowFPS"=dword:00000000

[HKEY_CURRENT_USER\Software\Travis Cobbs\LDView\Sessions\Thumbnails\ExtraSearchDirs]
"Dir001"="D:\\LEGO\\ldraw\\lsynth"
Reply
Re: LDView 4.2 Beta 1 Released
#34
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.
Reply
Re: LDView 4.2 Beta 1 Released
#35
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.
Reply
Re: LDView 4.2 Beta 1 Released
#36
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).
Reply
Re: LDView 4.2 Beta 1 Released
#37
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.
Reply
errors in 8464.mpd
#38
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.


Attached Files
.mpd   8464.mpd (Size: 52.62 KB / Downloads: 0)
Reply
Re: LDView 4.2 Beta 1 Released
#40
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.
Reply
Re: LDView 4.2 Beta 1 Released
#45
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.
Reply
Re: LDView 4.2 Beta 1 Released
#41
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.
Reply
Re: LDView 4.2 Beta 1 Released
#43
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.
Reply
Re: LDView 4.2 Beta 1 Released
#42
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...
:-))
Reply
Re: LDView 4.2 Beta 1 Released
#44
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.
Reply
Re: LDView 4.2 Beta 1 Released
#46
I can't find again the option to change highlight color in tree view...???
Reply
Re: LDView 4.2 Beta 1 Released
#47
Well, that's odd. I'll have to investigate where that disappeared to and put it back.
Reply
Re: LDView 4.2 Beta 1 Released
#48
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.
Reply
Re: LDView 4.2 Beta 1 Released
#49
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.
______________________________________________
OS = Ubuntu 14.04 LTS (64bit)
Reply
Re: LDView 4.2 Beta 1 Released
#57
I'm a big fan of your program, and I'd appriciate a PowerPC version.

Thanks.
Reply
Re: LDView 4.2 Beta 1 Released
#58
Unfortunately, I don't know how to create one. Apple has made it either extremely difficult or outright impossible to create PowerPC binaries using the development tools in Snow Leopard (which is the OS on my only Mac).
Reply
Re: LDView 4.2 Beta 1 Released
#60
I found this thread on the subject: http://stackoverflow.com/questions/53334...to-xcode-4

It looks like you'd have to intall Xcode 3. I have it on my system. I wonder if I could open your source files and compile them. Anyway, I'm just letting you know there is an audience for PowerPC if you happen to figure it out. Thanks for the great work so far.
Reply
Re: LDView 4.2 Beta 1 Released
#62
It looks like I had enough left on my computer from old installs (I upgraded it from Tiger to Snow Leopard, I think) to possibly make this work. Please try the build here:

http://www.halibut.com/~tcobbs/ldraw/pri...07.tar.bz2
Reply
Re: LDView 4.2 Beta 1 Released
#69
Can someone with a PPC Mac please give the above build a try and let me know if it works? If I don't get any feedback on it, I probably won't include PPC in the official release.
Reply
Re: LDView 4.2 Beta 1 Released
#70
I'm sorry I didn't write back sooner. I didn't check the forums because I wasn't expecting a response. It works great. Thank you very much for taking the time to accomodate me!
Reply
Re: LDView 4.2 Beta 1 Released
#71
You're welcome. Glad to hear it works. I'll include PPC in the official 4.2 release.
Reply
Re: LDView 4.2 Beta 1 Released
#59
I have a question for my users.

One of LDView's warnings is "Whitespace in filename..." Given that white space is officially allowed as per the current LDraw spec, do you feel that I should remove this warning from LDView?
Reply
Re: LDView 4.2 Beta 1 Released
#61
Maybe keep it for files with .dat extension but strip it for models. I believe parts should still be whitespace free.

Tim
Reply
Re: LDView 4.2 Beta 1 Released
#63
I think I like that. Plus, it makes my life easier, since it would take a fair bit of extra code to prevent the warning from showing up in the list of selected errors and warnings. (I can't just remove it from the list, because that would change the selected ones after it.) But do you think .dat is the best switch? Or should it be:
  • In LDraw/Parts, LDraw/Unofficial, or LDraw/p directory, or any subdirectory of the same OR
  • Contains part-specifying meta (like !LDRAW_ORG OFFICIAL_PART) OR
  • ? (I'm open for other suggestions.)
Reply
Re: LDView 4.2 Beta 1 Released
#64
My suggestion was based purely on ease of implementation not robustness. Choosing by directory would probably be the best. If it's in any of those directories it really oughtn't have whitespace.

Tim
Reply
Re: LDView 4.2 Beta 1 Released
#65
What's a whitespace?
Reply
Re: LDView 4.2 Beta 1 Released
#66
Ascii code 0x20, character you get when you hit space bar on your keyboard, blank space between words, etc Wink
Reply
Re: LDView 4.2 Beta 1 Released
#67
U-hu, and when is that considered to be an error?
Reply
Re: LDView 4.2 Beta 1 Released
#68
Currently, LDView generates a warning when it encounters white space in the filename of an LDraw file in a type 1 line. When LDView 4.1 was released, this was perfectly reasonable, because even though LDView could load such files (using the same algorithm as MLCAD), the LDraw spec didn't mention how that should be done.

Since then, the LDraw spec has been updated to standardize the algorithm MLCAD uses, so warning about white spaces in filenames is no longer really a good idea. However, DAT files in the official library are not allowed to use spaces in their filenames, so I plan to go with Tim's suggestion, and leave the warning in, but only when processing a part, sub-part, or primitive.
Reply
Re: LDView 4.2 Beta 1 Released
#72
I just tried to add a link to LDView in "file converters" section of LDraw website (I'm a bit tired of suggesting it to people that need to convert LDraw to other 3D formats Wink, but I couldn't ("ERROR: This URL is already listed in the database!"). Any way around?
Reply
Re: LDView 4.2 Beta 1 Released
#73
Just wait a little while longer and we're going to switch to the new site
Reply
Re: LDView 4.2 Beta 1 Released
#74
Any plans to port LDView to android?

I find this for java, but seems beta and dificult to compile for non-java programmers:

http://www.youtube.com/watch?v=bHahOgDz7TQ

http://code.google.com/p/foo-org-ve/

By the way, version 4.2b1 runs ok on Ubuntu 12.04, ¡good job!

Regards
Reply
Re: LDView 4.2 Beta 1 Released
#75
pillabichos Wrote:Any plans to port LDView to android?

No. I have no Android devices, and don't really plan to have any. Also, a port would be fairly difficult, since talking to native C++ code (which LDView is) from Java isn't very nice. Until two other LDraw viewers showed up for iOS, I had considered an iOS port, but iOS programs can easily talk to native C++ code.

pillabichos Wrote:I find this for java, but seems beta and dificult to compile for non-java programmers:

http://www.youtube.com/watch?v=bHahOgDz7TQ

http://code.google.com/p/foo-org-ve/

If someone wants to make something out of that for Android, that's fine, but it wouldn't be LDView, since it's not related. And I won't be doing it; I used Java in my job for a while, and never grew to like it, so I'm not likely to do it for fun.

pillabichos Wrote:By the way, version 4.2b1 runs ok on Ubuntu 12.04, ¡good job!

Thanks. I'm glad it works there.
Reply
Re: LDView 4.2 Beta 1 Released
try Buf3D
https://play.google.com/store/apps/detai...plus.buf3d
Reply
Re: LDView 4.2 Beta 1 Released
#76
If you have an edge line overlapping a condline (eg. when a portion of cylinder meets a quad at an angle), it would be great if the smoothing action of the condline was disabled...
Reply
Re: LDView 4.2 Beta 1 Released
#77
Thanks for the suggestion. I definitely agree, but I'm not sure how easy it will be to implement. I'll investigate.
Reply
Re: LDView 4.2 Beta 1 Released
#87
Any news on this?
Reply
Re: LDView 4.2 Beta 1 Released
#88
Sorry, but no. It seems unlikely it will make it into the official 4.2, though, given how little time I've had to work on LDView lately, and how long it's taking me to get it out the door.
Reply
Re: LDView 4.2 Beta 1 Released
#89
Sad
...But I can easily understand you!
Reply
Re: LDView 4.2 Beta 1 Released
#86
Windows 7 Home Premium 64-Bit / i7 950 /12 GB DDR3 SDRAM / Nvidia GeForce 460 (2x) / Samsung Syncmaster P2770

I was in despair ! I had a lot of troubles with LPub 4.0.0.11 in conjunction with LDView 4.1. With a relative complex design using a submodel repeated several times LPub was not able to finish up without crashing after about 80% of instructions generating. Reducing quality in LDView was helping a little bit but couldn't solve the problem. So I "discovered" your announcement about LDView 4.2 Beta and tried out the 64-Bit version. The result is phenomenal ! It runs 3 to 5 times faster and all the problems with cooperating between LPub and LDView are blown away !

Thanks Travis for this great upgrade ... You are the knight in shining armor :-)

Arthur

If you are able to "give away" some computing capacity install BOINC and help scientists to find a needle in a haystack (e.G. LIGO Laser Interferometer Gravitational Wave Observatory)
-----
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
Reply
Re: LDView 4.2 Beta 1 can't export to povray
#90
LDView 4.2 beta1 can't export to povray correctly, I only get a contour:

[Image: busespacialmal.png]

It did work with older versions but now I use ubuntu 12.04 LTS 64 bits and older versions don't work anymore.

This is my hardware:

lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.3 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem (rev 03)
04:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
Reply
Re: LDView 4.2 Beta 1 can't export to povray
#91
I will investigate. I've never seen that problem, but I haven't personally tested POV export on Linux (32-bit or 64-bit).
Reply
Re: LDView 4.2 Beta 1 can't export to povray
#92
If you want to I can try it with a kubuntu distribution.

/Max
Reply
Re: LDView 4.2 Beta 1 32 bits export ok, 64 bits ko
#93
I try again with 32 bits version export to povray runs ok.

But If I try to print ldview stop suddendly.
Reply
Re: LDView 4.2 Beta 1 Released
#94
Will LDView 4.1 and 4.2 beta play nicely together if they are installed at the same time? 4.2 beta freezes often so I want to avoid using it except when I really need to for now. Thanks.
Reply
Re: LDView 4.2 Beta 1 Released
#96
They'll work fine together, but if you have Explorer thumbnails enabled, the behavior there could be strange. I'm pretty sure the Explorer thumbnails feature will use the version of LDView that has been run most recently. So, if you run LDView 4.1 to view a model, then browse to a directory containing LDR files, Explorer will generate thumbnails using LDView 4.1. If you then run LDView 4.2 to view some other model, Explorer will then generate thumbnails using LDView 4.2.

So, if you are experiencing crashes in LDView 4.2, it might be best not to have the Explorer thumbnails feature enabled. Note that unless you know how to use regsvr32 /u, the only way to disable the thumbnails feature is to uninstall LDView. (You can then reinstall LDView with that option disabled in the installer.)
Reply
Part loading problem
#97
the motor X581C01.dat don't loads right- it throws a part missing error out : x581s01.dat and x581s01.dat are missing. ( error loading submodel).
But this subpart are in my unofficial folder (in the s folder), where the X581C01.dat reference to.
So why is it not loaded correctly?
By the way SR 3D builder loads it completely.
Reply
Re: Part loading problem
I just downloaded x581c01.dat into my Unofficial/parts folder, and then loaded it from there. LDView automatically downloaded the subparts into Unofficial/parts/s, and the file loaded fine. When you say "unofficial folder (in the s folder)", do you mean Unofficial/parts/s? Because if you put the files elsewhere, it probably won't work.

Also, if you enable LDView's automatic download of unofficial parts, it should download the subfiles automatically (and the motor itself also, if you load a file that references it).

Are you by any chance running on Linux? Because I notice you're using capital letters in the filenames, and that might cause problems on Linux on a case-sensitive file system. However, if you let LDView download the files for you, there shouldn't be a problem.
Reply
Re: Part loading problem
x581c01.dat is in my Unofficial/parts folder and the subparts are in the Unofficial/parts/s and it is still not working.
I'm running LDView mainly in Win7.

I also recognized that the part itself loads fine, when I load the x581c01.dat directly in LDView.
The problem come when I use it in a model.
I just attached a file in which x581c01.dat is in a model (Very simple just this part, but the error occurs everytime it is used in a model)


Attached Files
.l3b   motortest.L3B (Size: 1.03 KB / Downloads: 0)
Reply
Re: Part loading problem
I only see a x581.dat not a x581c01.dat

It also seems that there are outdated unofficial parts are used.

Using unofficial files is always on your own risk!
Reply
Re: Part loading problem
Why do you use it like that? The assembly x581c01.dat is fully inlined in that example.

You only have to add s\ infront of the subfiles x581s01.dat and x581s02.dat.
Like this:
1 494 0 40 90 1 0 0 0 -1 0 0 0 -1 S\X581S01.DAT

Or simply use only x581c01.dat instead.
Reply
Re: Part loading problem
This file I attached is the result of just selecting x581c01.dat in the toolbox of SR 3D builder and placing it in the model space and then saving it. Maybe a problem with SR 3D Builder??
By the way I use a clean fresh install of the latest official part and also downloaded and installed all unofficial parts only a couple of days ago.
But I realized that SR 3D Builder somehow deletes unofficial parts in the rebuild part list process.
But that only concerns duplicated parts, which are in the official and unofficial folder. see here
So I don't know why this part get saved this way. Mabye I should report it on the SR 3D Builder forum....
Reply
Re: Part loading problem
yes.
if this is expected to be a model just containing the x581c01.dat assembly,
the file is malformed. as already said, the 2 errors are:
- the part has been inlined instead of instantiated
- all referenced subfiles lack the s\ folder prefix
Reply
Re: Part loading problem
They lacks the s/ or they should also be inlined - completely.

I _guess_ this is a bad behaviour of SR-3d Builder.
Reply
Re: Part loading problem
Yes, that's a problem of SR3D with assemblies made of subparts (kind of wrong practice on LDraw side indeed, but we do have a lot of old parts made this way). I had recently the same issue with NXT connectors...
Reply
Re: Part loading problem
I reported this error to Sergio at the SR 3D builder forum and got this answer.
So, who has now to chance what??
Ldraw library or the application using it?
Reply
Re: Part loading problem
As far as I know Sergio is correct that the shortcut part should not reference primitives. It should only reference components.

But... good programming does not expect perfect inputs. He should really fix that bug.

Tim
Reply
Re: Part loading problem
Code:
As far as I know Sergio is correct that the shortcut part should not reference primitives. It should only reference components.

But... good programming does not expect perfect inputs. He should really fix that bug.

Tim

A quick look at the PT shows that:
1) this is currently an unofficial part, so there might be errors Smile
2) there is no direct reference to a primitive
3) the subparts should be changed to be parts
4) Tim is quite right with the last statement Smile 1+
Reply
Re: Part loading problem
Quote:2) there is no direct reference to a primitive

Really? I looked again at x581c01.dat and found 4-4cyli.dat, 4-4cylo.dat as reference in it. I think these are primitive.
I'm no part author so maybe I got something wrong. These primitivs are beneath a BFC statement, but chance that anything?
Reply
Re: Part loading problem
Grr....
You are completely right and I am stupid Sad

As those files are from me, i think I need to update them quickly Smile
Reply
Re: LDView 4.2 Beta 1 - illegal characters when exporting
#98
Some of my models have "+", "-" and similar characters in their file names. This is not a problem until you try to export them to POV-Ray, which doesn't allow them.

I'm not sure what to do in this case. Does LDView need to be modified to handle them? There should be a warning whatever the case.
Reply
Re: LDView 4.2 Beta 1 - illegal characters when exporting
#99
My developer code now has a big list of special characters in the POV exporter (much bigger than before). In addition to space and tab, all of the following characters will be replaced:

Code:
.-/\#:!()[]{}&~`@$%^*+='";|?<>,
Reply
Re: LDView 4.2 Beta 1 - illegal characters when exporting
will there be a 4.3 someday containing all fixes which have been aggregated so far?
Reply
Re: LDView 4.2 Beta 1 - illegal characters when exporting
Actually, it will be 4.2. (I am in bug fix mode.) It should have been released a long time ago, but I just haven't found myself spending enough time to fix the known bugs and get the official 4.2 out the door.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)