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

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

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

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

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

exported .pov files contain these lines at their beginning:
#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:
#declare LDXEdges = union
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:
#if (LDXEdges > 0)
#declare LDXEdgesObject = union
#if (LDXEdges > 0)
   object { LDXEdgesObject }
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:
#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."
#if (LDXEdges > 0)
   object { LDXEdgesObject }

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

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.

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

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.

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

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.

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

yep, nice

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

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.

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

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:



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

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


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

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

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.

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

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