More ways of ldraw parts usage then rendering them


More ways of ldraw parts usage then rendering them
#1
As opposite to strictly technical topics I start this one as kind of "an evening talk in a pub" or "brainstorming" if you wish: I'm really interested in your ideas and opinions.

I start with a question: do you know the difference between old geographic maps (==pictures) and modern ones, like the openstreetmap project? Modern map is considered being a list of discrete objects and each such object is defined in the text: a path joining points etc. See? Very similar idea to our ldraw format! But there is an important addition, comparing to ldraw: they have very well defined system of metainformation: object types, their capabilities... And the result is: such a map can not only be rendered to a picture form (with any graphical style) but it can be used for completely different tasks. One such task is well known for everybody, nowadays: a car navigation. But even a simple search in the map is a task - de facto it is a database query.

What about thinking more about ldraw format in this way? Isn't there another space then part pictures where ldraw could help, if having proper metadata? Ideally the metadata we already have or could get easily from already existing information in ldraw files.

For example: every time I work on shadow/snapping information for LDCAD ideas of this kind come into my mind: part snapping is one example of non-pictural ldraw usage. What more can we use it for? What about queries? "Hey, my editor, show me gears matching this one", "show me a list of parts with a clip" etc. I slightly remember old SR3D editor did some magic in this way to animate models automatically (bending a hinge moved the attached parts of the model, technic drivetrain worked automatically etc.) but it's so long I do not remember details.

What do YOU think? Do you have any ideas?
Reply
RE: More ways of ldraw parts usage then rendering them
#2
(2022-07-06, 17:46)Milan Vančura Wrote: As opposite to strictly technical topics I start this one as kind of "an evening talk in a pub" or "brainstorming" if you wish: I'm really interested in your ideas and opinions.

I start with a question: do you know the difference between old geographic maps (==pictures) and modern ones, like the openstreetmap project? Modern map is considered being a list of discrete objects and each such object is defined in the text: a path joining points etc. See? Very similar idea to our ldraw format! But there is an important addition, comparing to ldraw: they have very well defined system of metainformation: object types, their capabilities... And the result is: such a map can not only be rendered to a picture form (with any graphical style) but it can be used for completely different tasks. One such task is well known for everybody, nowadays: a car navigation. But even a simple search in the map is a task - de facto it is a database query.

What about thinking more about ldraw format in this way? Isn't there another space then part pictures where ldraw could help, if having proper metadata? Ideally the metadata we already have or could get easily from already existing information in ldraw files.

For example: every time I work on shadow/snapping information for LDCAD ideas of this kind come into my mind: part snapping is one example of non-pictural ldraw usage. What more can we use it for? What about queries? "Hey, my editor, show me gears matching this one", "show me a list of parts with a clip" etc. I slightly remember old SR3D editor did some magic in this way to animate models automatically (bending a hinge moved the attached parts of the model, technic drivetrain worked automatically etc.) but it's so long I do not remember details.

What do YOU think? Do you have any ideas?

I have read this and I'm not really sure what you even mean
Reply
RE: More ways of ldraw parts usage then rendering them
#3
(2022-07-06, 17:56)Max Murtazin Wrote: I have read this and I'm not really sure what you even mean

Asking you to use both your experience and your imagination to come with more ideas what else than picture rendering we may use ldraw for.

As "a starter" I showed some examples from different area similar to ldraw insome way: geo-maps. Also in a textual form they allow not only (picture) map rendering but also database queries like "show me an open shop near to me with parking lot" or a car navigation using "a map" in a completely different way.

Back to ldraw: for example, I'm always surprised I cannot do queries like "what part has a clip". LDCAD shadow/snap information helps a little but still... And back to my original question: this is just a very small example, do you haveany idea what we can use ldraw for?
Reply
RE: More ways of ldraw parts usage then rendering them
#4
(2022-07-06, 18:11)Milan Vančura Wrote: Asking you to use both your experience and your imagination to come with more ideas what else than picture rendering we may use ldraw for.

Literally only actual purpose of LDraw is making lego builds digitally, and there's not much need for there to be anything else
Reply
RE: More ways of ldraw parts usage then rendering them
#5
(2022-07-06, 20:27)Max Murtazin Wrote: Literally only actual purpose of LDraw is making lego builds digitally, and there's not much need for there to be anything else

OK, so you have no more needs than it's already available and this discussion is not for you. No problem.

I have some ideas and at some specific moments, like when I'm short on time with my models, I have a strong feeling I have SO MANY ideas for ldraw features making our lives easier Big Grin
But I do not want to start this topic as a discussion about my ideas, I'm much more interested in the others' ideas, experience, opinions - without influencing them in advance. The only I want to emphasize is the fact that we may look at ldraw set of files as a database, including metadata, not only as a set of "rendering recepics".
Reply
RE: More ways of ldraw parts usage then rendering them
#6
I used LDView in the past to locate errors in TDM based communication systems :-)

The error messages of the system were mapped onto a 2D area and the number of errors determined the height.
As Excel was too slow to render such things in a proper way, the matrx was too large, I used a macro that generated a LDR which you could view in LDView to pinpoint the issue.

[Image: testfile3.png]
Reply
RE: More ways of ldraw parts usage then rendering them
#7
Wow. 😲 !!!
Reply
RE: More ways of ldraw parts usage then rendering them
#8
Oh!

OK, OK - I asked to be surprised and I got what I requested for, that's fair Big Grin 

Although I must say I though about something different (usage of current ldraw files) I must say this is great idea!
Reply
RE: More ways of ldraw parts usage then rendering them
#9
(2022-07-07, 12:13)Milan Vančura Wrote: Oh!

OK, OK - I asked to be surprised and I got what I requested for, that's fair Big Grin 

Although I must say I though about something different (usage of current ldraw files) I must say this is great idea!

It was all about being able to move/rotate through the diagram in an apropriate speed, which Excel did not offer 12yrs ago, probably still not does, so this was the easiest visualisation :-)
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 3 Guest(s)