|
|
| |
In lugnet.cad.dev.lcd, Thomas Dickerson wrote:
> Greetings everyone,
> I am a newbie to this mailing list, but I have been using LDraw-oriented
> software for close to a decade now.
>
> I am currently developing (and have been, in my spare time for several years) a
> sandbox-style building game called FreeBuild oriented around the construction of
> (and combat with) Lego vehicles, spaceships, mechs, etc. Most of my time in the
> last year and a half has been dominated by ensuring my game engine will have the
> technical infrastructure to handle this task, and I am now ready to begin
> implementing the building portion of this game, which I am basing around the
> LDraw parts library. I am working with a derivative of the LDLITE lexer/parser
> (with permission from Paul Gyugyi, the original author), and am in the process
> of modifying it to suit the needs of my application. Part of this process
> modifying it to support the Colour Definition Language Extension instead of the
> proprietary-to-LDLITE color metacommands currently present in the parser.
>
> The documentation for both version 1.0.0 of the core LDraw file format, and for
> the Colour Definition language extension mention several language features which
> they do not fully document. The Colour Definition language extension lists
> "DITHER" as a valid keyword tag to be used as part of a 0 !COLOUR line, but
> fails to document the arguments which can be supplied to it, and how they should
> be interpreted.
>
> The file format document itself mentions both "Direct Colors" and what appears
> to be a competing specification for blended/dithered colors, but does not
> specify how either of these would appear within a part or model.
>
> Any information that could be provided on these language features, or the
> prevalence of direct colors within models "in the wild" would be extremely
> helpful to my implementation and optimization for using LDraw files within my
> game engine.
>
> Many Thanks,
> Thomas Dickerson
Hello,
First of all, I think you are in the wrong news group. LCD is about connections
not colours. You probably better of in the main lugnet.cad.dev group
Second you are right about the DITHER keyword, personally i think it is a typo
and shouldn't be mentioned at all in the spec.
Dithering is the way old software worked using color code 256 upto 511 these are
leftovers from cga and vga times.
The !COLOUR meta doesn't need dither information cause it's a fullcolour (24bit
rgb, 8 bit alpha) spec. And imho it's upto the software interpreting the meta
how to display those colors, hence the 'hints' like metal, rubber etc.
Roland
|
|
| |
Greetings everyone,
I am a newbie to this mailing list, but I have been using LDraw-oriented
software for close to a decade now.
I am currently developing (and have been, in my spare time for several years) a
sandbox-style building game called FreeBuild oriented around the construction of
(and combat with) Lego vehicles, spaceships, mechs, etc. Most of my time in the
last year and a half has been dominated by ensuring my game engine will have the
technical infrastructure to handle this task, and I am now ready to begin
implementing the building portion of this game, which I am basing around the
LDraw parts library. I am working with a derivative of the LDLITE lexer/parser
(with permission from Paul Gyugyi, the original author), and am in the process
of modifying it to suit the needs of my application. Part of this process
modifying it to support the Colour Definition Language Extension instead of the
proprietary-to-LDLITE color metacommands currently present in the parser.
The documentation for both version 1.0.0 of the core LDraw file format, and for
the Colour Definition language extension mention several language features which
they do not fully document. The Colour Definition language extension lists
"DITHER" as a valid keyword tag to be used as part of a 0 !COLOUR line, but
fails to document the arguments which can be supplied to it, and how they should
be interpreted.
The file format document itself mentions both "Direct Colors" and what appears
to be a competing specification for blended/dithered colors, but does not
specify how either of these would appear within a part or model.
Any information that could be provided on these language features, or the
prevalence of direct colors within models "in the wild" would be extremely
helpful to my implementation and optimization for using LDraw files within my
game engine.
Many Thanks,
Thomas Dickerson
|
|
| |
Hi gang,
playing around with colors I was floored by the fact that we do not have a LDraw
color number or RGBs for quite a lot of LEGO colors. In addition our RGBs
sometimes differ a lot from the official colors:
http://www.peeron.com/inv/colors
http://www.peeron.com/cgi-bin/invcgis/colorguide.cgi
I remember the time when we were graving for those figures and now that we have
them I simply ignore them. Can anyone put some light on this? LSC?
Thx, w.
|
|
| |
Daniel Bennett schrieb:
> Hi
> I’m now working on GLIDE and clicking again. I have moved house and job which
> is why I have not done any work on GLIDE over the last 6 months or so. Version
> 0.74 is now available for download. http://www.mr-bucket.co.uk/GLIDE/index.html
> You can now set the background colour of an edit window. You can also add the
> current bricks colour to the pallet. There are a couple of bug fixes as well.
> Its worth looking at the key list in the help file.
Are there any improvements from that time?
It would be interesting.
cu
mikeheide
|
|
| |
I proxy this on behalf of Sergio Reano, who for some technical reasons is not
able to post to LUGNET. Please post here your comments but cc: also to Sergio
via mail.
Hi everybody,
my name is Sergio Reano and I'm a programmer and Lego fun from Italy.
In the last few years I have had little time to play with real bricks and
decided to mix passion and informatics to create a new Lego CAD software to
enjoy Lego at least while I was in front of the screen.
The program I came up with, called SR 3D Builder, is IMHO very innovative
compared to MLCad or Lego Digital Designer 'cos it is able to recognize
automatically connections between LDraw parts and, based on that, to manage
hinges, rotation axels, gears. Additional functionality is planed for the
future.
To allow connection detection, I have associated the most common connections
like studs, axles, pins with the subpart representing an existing connection. In
short: every time the program finds a STUD.dat subpart it adds a connection of
the STUD type with the same coordinates. The connections it manages are almost
the same you can find in http://www.ldraw.org/Article135.html, but minifigs and
most of the hinges are still not implemented.
Problem is; it's really hard to create a connection when there is no subpart I
can associate with. The only way I found was to patch every single .dat part by
hand, adding lines which describe this kind of connection (especially hinges).
The program plus the patched parts definitions can be freely downloaded from
http://staff.polito.it/sergio.reano (a link has also been added to the download
section at LDraw.org). Please have a look at it and let me know what you think
about.
As you might already guess there are a lot of parts to patch, and I'm feeling
kind of lost with the huge library out there. What I'm looking for are helping
hands to patch the parts (the software you'll need will be provided).
Furthermore, I would like to establish contact with someone of the LDraw
organization in order to work out a standard for the connections.
I have contacted Willy Tschager and he has proposed a standard based on meta
commands:
0 !NEW CONNECTION conn_type, xpos,ypos,zpos, xorient, yorient, zorient
where
- conn_type identify connection type (stud, hinge, ...)
- x,y,z pos identify connection position
- x,y,z orient identify connection orientation
which would be ok for me, even though I currently use a different code (you can
find the technical specification on my site).
I would be really happy hearing form you (especially form those willing to patch
;-) You can contact me at: Sergio[dot]reano(at)polito{dot}it
Thank you,
Sergio
|
|
|
