Sometimes I myself don't notice new versions of programs which appear,
so I'd like to share some news here:

I just spotted that

POVRay 3.7 beta

http://www.povray.org/beta

is out. My previous version was 3.62.

The most important thing about it is that it runs on multiple (all) CPU cores now,
giving you a huge speed boost. It is definetely worth a try.


For people who not yet had used povray with LDraw: just open any *.ldr (or *.dat or *.mpd) file you like
in LDView, and choose File/Export to save it as a *.pov file.
You can then simply open that file in povray, hit the "run" button and will see a nice 3D raytracing rendering
of your scene.


Things to mention:

(a)
From this version on, povray suggests to put a #version statement to the very beginning of each file,
telling of which version the syntax in that file is. This allows newer versions to read files for older versions
and behave that way. If you don't do that, you get a warning. I'm just trying to figure out if for me
#version 3.5;
or
#version 3.6;
or
#version 3.7;
works best.
see also http://news.povray.org/povray.beta-test/...ay.org%3E/

(b)
A similar thing is with the gamma setting. The povray people seem to want to change their default
which previously appeared too bright for some platforms, and too dark for others. (That's also my experience.)
However, changing that default would have broken existing scenes, this is why they probably introduced the #version
requirement described in (a). Read the povray documentation to find out more. For me,
global_settings { assumed_gamma 2.2 }
on the PC works quite well.
see also http://wiki.povray.org/content/HowTo:Fix...mma_system

©
I found some of the new messageboxes quite nagging - YMMV


Have fun!

I just wanted to reply to http://forums.ldraw.org/showthread.php?tid=4401,4401
, but couldn't, so I am forced to post here.

I think that that voting is on a good way, but I think that the Mac users have been forgotten.
The currently suggested new text says
"it is recommended that applications understand CRLF and LF as line endings".
I think that that should be instead
"it is recommended that applications understand CRLF and LF and CR as line endings".

Please vote on the proposal below. Please modify the Subject to include your name and vote, in addition to giving your vote in the text.

Quote:Line Termination

All lines in the file must use the standard DOS/Windows line termination of <CR><LF> (carriage return/line feed). The last two bytes of the file must be <CR><LF>. (In other words, there must be a <CR><LF> line terminator at the end of the last line in the file.)

Quote:Line Termination

All lines in the file must use the standard DOS/Windows line termination of <CR><LF> (carriage return/line feed). The file is permitted (but not required) to end with a <CR><LF>. It is recommended that all LDraw-compliant programs also be capable of reading files with the standard Unix line termination of <LF> (line feed).

Here is an update of my VisualLDconfig mpd, including colours defined in LDconfig.ldr update 2012-01-06.

Brickshelf folder with more renderings (after validation)

Attached Files

  visualLDconfig.mpd (Size: 384.45 KB / Downloads: 0)

Please vote on the proposal below. Please modify the Subject to include your name and vote, in addition to giving your vote in the text.

Quote:Unofficial parts are allowed to be used. The filename of the unofficial part is subject to the naming rules above (e.g. 33056.dat would be renamed to <MPD Filename> - 33956.dat).

Quote:Unofficial parts are allowed to be used. The filename of the unofficial part is subject to the following naming rules:

<Set Number>[-<Optional Qualifier>] - <Unofficial Part Number>.dat

<Set Number> is the the number printed on the model's container.
<Optional Qualifier> is a sequential number, starting with 1, added if there is more than one set that could be assigned <Set Number>
<Unofficial Part Number> is the unofficial part number assigned in that very moment

(e.g. 33956.dat would be renamed to 3345 - 33956.dat or 3345-1 - 33956.dat).

Interesting read: Dissertation by Mathew Wolfe

http://www.cs.bath.ac.uk/~mdv/courses/CM...007-08.pdf

w.

I apologize for not having been able to respond to any communications sent to me. I have been called up to active duty and will be deploying to Afghanistan in June, and we have had a lot of training recently. I will attempt to post any active parts I have been working on in the hopes that someone who has the time might complete them, otherwise I'll resume working on them when I return next year. Thanks.

Phil Peickert

Looking at the old held or non-ca parts, I thought I'd tackle a group of them at once:

6162 33230 6161
and add 47115 (similar to 6162).

I noticed some discussion on stud4f4n.dat about standardizing these extra primitives, and would like to take it one step further.

Before I uploaded a bunch of new primitives, I thought I'd share my thoughts and see what others think.


The flanges on the stud4f's could extend to the meet the next flange, and additional stud4's with longer flanges could be used for edges and corners. This would reduce the file tree and number of polygons used for each rib.

Groups for single- and double-spaced stud4f's and double-spaced stud4's could be created for the standard cases (4 flanges).

Ribs and rib-groups to make up between double-spaced stud4's and edges could also be created.

I've attached a couple preliminary files to show my thoughts about the non-flush ribs and double-spaced stud groups.


None of the stud4f's are released yet, and the parts that use them aren't either.

Opinions?

Attached Files

  stug4-1x4a.dat (Size: 399 bytes / Downloads: 0)
  stug4-4x4a.dat (Size: 419 bytes / Downloads: 0)
  rib4a.dat (Size: 521 bytes / Downloads: 0)
  rib4b.dat (Size: 497 bytes / Downloads: 0)
  rig4a1x4.dat (Size: 401 bytes / Downloads: 0)

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

https://www.youtube.com/watch?v=tyijTDuotu4

another SEOC