| Welcome, Guest |
You have to register before you can post on our site.
|
| Forum Statistics |
» Members: 5,613
» Latest member: Maty
» Forum threads: 6,379
» Forum posts: 52,950
Full Statistics
|
| Online Users |
There are currently 174 online users. » 0 Member(s) | 170 Guest(s) Baidu, Bing, Google, Yandex
|
| Latest Threads |
Complex Figures (Duplo/Te...
Forum: Official File Specifications/Standards
Last Post: Chris Böhnke
6 hours ago
» Replies: 0
» Views: 14
|
LDCad 1.7 Beta 2 (win+lin...
Forum: LDraw Editors and Viewers
Last Post: Magnus Forsberg
9 hours ago
» Replies: 21
» Views: 1,656
|
6x8x2 "helicopter" Windsc...
Forum: Part Requests
Last Post: Rene Rechthaler
Yesterday, 18:08
» Replies: 1
» Views: 72
|
LEGO Parts Guide - Only 4...
Forum: Part Requests
Last Post: Javier Orquera
Yesterday, 17:38
» Replies: 26
» Views: 2,836
|
LDraw.org 2026-01 Parts U...
Forum: LDraw.org Announcements
Last Post: Orion Pobursky
2026-01-30, 15:05
» Replies: 2
» Views: 305
|
A Friends's little help t...
Forum: Parts Authoring
Last Post: Takeshi Takahashi
2026-01-30, 14:32
» Replies: 2
» Views: 396
|
LDraw Colors for OpenScad...
Forum: LDraw Editors and Viewers
Last Post: Hageta
2026-01-30, 11:46
» Replies: 0
» Views: 97
|
LDConfig with Bricklink S...
Forum: LDraw File Processing and Conversion
Last Post: Hageta
2026-01-30, 11:43
» Replies: 0
» Views: 125
|
7660 not showing in parts...
Forum: Parts Authoring
Last Post: SNIPE
2026-01-30, 7:12
» Replies: 3
» Views: 181
|
LEGO Icons 2025
Forum: Official Models
Last Post: Franklin W. Cain
2026-01-30, 2:48
» Replies: 6
» Views: 6,461
|
|
|
| 2026/2027 LDraw.org Steering Committee (SteerCo): List of nominees |
|
Posted by: Willy Tschager - 2026-01-21, 10:27 - Forum: LDraw.org Announcements
- No Replies
|
 |
A quick reference to the candidates for the 2026/2027 LDraw.org Steering Committee (SteerCo) election. The information is drawn from the nomination process and corrections are welcome, please email the webmasters.
Candidates are listed by nomination status in alphabetical order by last name and no ranking or endorsement should be inferred from their position on the list. The following table summarizes the status of each candidate in the format:
Nominee name: Nomination Status (Nominator, Second)
Chris Böhnke: Accepted (N. W. Perry, Philippe Hurbain)
Philippe Hurbain: Accepted (Johann Eisner, Rene Rechthaler)
Gerald Lasser: Accepted (Rene Rechthaler, Philippe Hurbain)
N. W. Perry: Accepted (Philippe Hurbain, Willy Tschager)
Orion Pobursky: Accepted (Jaco van der Molen, Johann Eisner)
Rene Rechthaler: Accepted (Chris Böhnke, Philippe Hurbain)
Lisa Winter: Accepted (Willy Tschager, Orion Pobursky)
Peter Blomberg: Not yet accepted (N. W. Perry, Willy Tschager)
Evert-Jan Boer: Not yet accepte (Willy Tschager, Orion Pobursky)
Magnus Forsberg: Not yet accepted (Philippe Hurbain, Gerald Lasser)
Peter Grass: Not yet accepted (N. W. Perry, Philippe Hurbain)
Fredrik Hareide: Not yet accepted (N. W. Perry, Philippe Hurbain)
Max Martin Richter: Not yet accepted (Willy Tschager, Orion Pobursky)
Takeshi Takahashi: Not yet Accepted (N. W. Perry, Philippe Hurbain)
Johann Eisner: Declined(Willy Tschager, Orion Pobursky)
Nils Schmidt: Declined (Chris Böhnke, Rene Rechthaler)
Willy Tschager: Declined (Johann Eisner, N. W. Perry)
Replies to this have been disabled. The nominations thread is where they belong.
|
|
|
| How to run Studio on Linux/Ubuntu. |
|
Posted by: Amiiyah - 2026-01-19, 22:42 - Forum: Off-Topic
- No Replies
|
 |
Install Lutris, and download Studio.
After Studio is installed, right click it, and click Configure, then Game options and write this command into the Arguments tab: -dx11 -windowed -ResX=128 -ResY=128.
Studio will run without crashing or freezing.
|
|
|
| Discussion - proposal to extend !TEXMAP specification |
|
Posted by: N. W. Perry - 2026-01-19, 19:08 - Forum: Official File Specifications/Standards
- Replies (21)
|
 |
The summary here brings together many of the issues already considered, in the hope that it can lead us to the next steps forward.
Abstract
This is a proposal to extend the current !TEXMAP specification to include LDRAW and SVG formats, along with the existing support for PNG.
Background
The !TEXMAP language extension allows LDraw tools to map a bitmap image, in .png format, onto a part surface or other LDraw geometry as a texture. The !TEXMAP meta-statement specifies the scope of the texture application, as well as a projection method and its associated parameters, and a source .png file.
The associated !: meta-statement provides, in LDraw code, the geometry on which the texture is to be applied. This can be followed by an optional FALLBACK statement, providing the geometry to be used by LDraw tools that do not recognize the !TEXMAP language extension. (Those that do will ignore this geometry.)
The source .png file can be located in the textures/ folder (or elsewhere) within the active LDraw directory tree, or it can be embedded as base64-encoded binary data within a multi-part LDraw document, using the !DATA language extension.
!TEXMAP is most often used to apply a pattern (representing a printed image on real-world parts) to an LDraw part (or sticker). It is intended as an alternative to the traditional method of creating patterns, in which standard LDraw geometry (triangles, quads, lines, primitives, etc.) is used to draw the pattern and assign its colors. !TEXMAP is considered appropriate when the pattern is highly detailed or intricate, has a photographic quality, or is otherwise unsuitable for the traditional method, which is otherwise generally preferred.
As a result, while easier to implement, the !TEXMAP method is often discouraged by parts authors and reviewers, and as a result is found only in a relatively small number of official library parts.
Proposal
The proposed extension to the !TEXMAP specification would add support for vector-based geometry formats, by allowing patterns in LDRAW and SVG format, as well as bitmap images via PNG, to be mapped onto LDraw geometry. This would involve a minimal change to the existing specification, by enabling <ldraw> or <svgfile> as alternatives to the current <pngfile> argument (and by inserting any restrictions or requirements for LDraw or .svg files). Theoretically, the specification could be left open to the addition of possible future formats that may one day be supported.
Implementation, as always, is left to the developers of LDraw tools. Presumably, LDraw geometry would be prepared for rendering as usual, but before being finalized (and after applying any applicable primitive substitution), the rendered data would first be mapped onto the target geometry according to the selected projection method. SVG data could likewise be rendered and mapped, by use of various SVG-to-LDRAW conversion utilities that may from time to time be in development.
A related extension may be necessary to the !DATA specification, to allow embedding of SVG code into a multi-part document. Because SVG code is human-readable and not binary data, a new !CODE meta-statement could be created to allow this kind of data to be embedded. (LDraw code can, of course, already be embedded by using the FILE meta-statement, but the !CODE meta might also allow the insertion of LDraw code as a snippet, thus not requiring full headers and other LDraw file requirements.)
Rationale
The traditional method of creating patterns already involves using LDraw geometry. However, the ability to map LDraw code onto an existing surface using !TEXMAP would have several advantages: - It would greatly simplify the authoring process for patterns appearing on non-planar surfaces, especially in parts with complex or highly organic forms (such as animals) since the pattern geometry would only need to be created in a 2D version.
- It would allow the projection of LDraw geometry onto curved surfaces without interrupting the visual appearance of these curvatures (the so-called "crumpled paper" effect).
- This could also have applications in situations involving non-patterned geometry, such as when curved primitives are juxtaposed with non-primitive geometry that represents a curved surface (but where applicable primitives don't exist), resulting in visible seams or undesirable flat spots (for example, the lower edges of 3941.dat).
- It would encourage more participation by parts authors by enabling the more user-friendly, less labor-intensive !TEXMAP process to be used, without the perceived disadvantages of .png textures (see referenced discussion above).
- It would allow for a pattern to be mapped onto any base part, rather than needing to create a separate library part for each patterned version. Library entries for patterned parts could consist simply of an LDraw code snippet and an associated !TEXMAP statement, referenced to an existing base part in the library.
- Besides the geometry, it could also allow for other LDraw information, such as color, to be mapped. This could permit the creation of different-colored versions of a single pattern file, by using either inherited colors or direct color replacement.
The proposal also includes SVG support, which offers these additional advantages: - SVG format is fully scalable, allowing for essentially unlimited resolution of pattern images, whereas LDraw vector geometry is necessarily limited in resolution (even allowing for techniques such as primitive substitution). In theory, with support for SVG combined with texture mapping projection methods, the SVG format could conceivably supplant the need for LDraw-coded pattern geometry altogether.
- Vectorization of bitmap images is already a process step for many authors of LDraw patterns, with FOSS tools for SVG, such as Inkscape, readily available. Direct application of SVG graphics to an LDraw part would thus save many additional process steps.
- A similar case exists with img4dat, for conversion of bitmap images directly to LDraw code.
- There are already multiple tools, at varying levels of development, for converting SVG to LDRAW format (the most complete probably being Lasse Deleuran's svg2ldraw), which could presumably be incorporated into LDraw editors without starting from scratch.
Potential Issues / Questions - Generating stickers: One potential enhancement to this system would be to project the texture so that it stands 0.25 LDU proud of the target geometry. A process would then be applied to generate the remaining geometry necessary to complete a sticker back, thus obviating the need to create individual sticker parts (and thus simplifying library entries, similar to direct-patterned parts as outlined above).
- Inclusion of this functionality is ideal, as it would complete the simplification of the authoring process for all patterns, whether as printed parts or stickers. However, it adds considerable complexity to the implementation.
- Nevertheless, such functionality is not unheard of; for example, adding sticker thickness is already an available option in svg2ldraw, above.
- Third-party tools, such as Blender, can also be used to extrude a mesh in this fashion.
- Additional projection methods: The three existing methods (planar, cylindrical and spherical) may or may not be appropriate for mapping textures generated from LDraw or .svg code. Would it be necessary to explore additional projection methods?
- Lasse's Pattern Folder utility may offer other approaches to projecting LDraw geometry onto a variety of surfaces.
- Primitive substitution: This is a complicating factor in mapping LDraw geometry. It would be desirable to retain such functionality, or else the texture mapping loses much of its advantage as far as image resolution. Any implementation of LDraw code mapping should allow for the inclusion of primitive substitution.
- However, full adoption of SVG format would provide the wanted image resolution without the need for prim sub.
All feedback is welcome. This seems like a promising idea to me, since it requires minimal alteration to the spec while providing a number of advantages to patterned parts authoring (and beyond), while also offering some potential streamlining of the parts library. (There is no doubt that patterned parts will continue to be among the fastest-growing category.)
It also seems to draw upon ideas already shared by many LDraw users, and can benefit from functionalities already fairly well-developed both within and outside the LDraw universe. As always, I am by no means a programmer, so there will be considerations I haven't thought of. But it does seem that this is much more a question of combining and refining existing capabilities, than it is of creating new ones.
Thanks for reading!
|
|
|
| 2026/2027 LDraw.org Steering Committee: Call for Nominations |
|
Posted by: Willy Tschager - 2026-01-19, 17:10 - Forum: LDraw.org Announcements
- Replies (48)
|
 |
Per the LDraw.org Bylaws at http://www.ldraw.org/article/268.html, Subsection
6.03(a), the 2025/2026 Steering Committee hereby calls for the community to nominate individuals as candidates for the 2026/2027 Steering Committee[1].
Please post nominations in response to this message. Nominations will only be recognized if they are in response to this message.
Per ss.6.03(a), you must specify the name of the person you are nominating, along with your name. Another member of the community must second the nominationin a reply, and the nominee must publicly accept the nomination in the same channel (direct reply to the nomination or second) in order to be valid. If the nominee does not accept, it will be assumed that he or she has declined, and they will not be placed on the ballot.
Nominations will close at 11:59 PM GMT on 28 February 2026. This means that to be listed on the ballot, a candidate must have been nominated, seconded and must have formally stated acceptance by that time.
The Steering Committee will give sufficient notice of the election and election procedures per ss.6.03(b).
NOTE: subsection 6.03(b) states that elections should take place before March 1. We interpret this to mean that we will commence the election on March 1, but
since it is electronic, it will run for 2 weeks, just as last time. The exact time and date of start and end will be announced sometime very close to (but after) 0000 GMT March 1.
Again, thanks to all of you for your commitment to the goals of the organization, and in working with us this year. Please, stay involved with LDraw.org and keep it moving forward!
Willy Tschager
On behalf of the LDraw.org Steering Committee
--
[1] Try not to confuse the LDraw.org Steering Committee (SteerCo) with the LDraw Standards Board (LSB). The Steering Committee sets the course for the LDraw Organization while the Standards Board deals with the LDraw File Format.
|
|
|
|