 | | | | | |
Hi.
Its nowhere near finished or even stable but if you want a look at a work in
progress.
www.mr-bucket.co.uk/GLIDE/
Since its only in alpha at the moment I'm not really looking for specific this
doesn't work that's broken replies. I would like to know what you lot think of
GLIDE so far though, and what features you would like to see added.
The long time lug neters among you may or may not remember I posted my first
version about a year ago. Article 10095. I have only just come back to working
on GLIDE so not a great deal has changed.
--Dan.
| | | | | | | | | | | | | | | |
Hi Dan,
This looks very good. Questions/suggestions/comments:
The interface looks like Leocad's one - is that a coincidence?
Please consider exporting to 3DS. Leocad does it, while Mlcad does not.
Unfortunately, updating Leocad's library is (used to be?) a bit of a pain. This
would be a great gap to bridge.
Will the camera definition allow adjustments in the Z axis (relative Z axis,
that is)? Adding that, plus the ability to export it to POVray, would be another
HUGE plus.
I guess I'm mostly asking for EXPORT options. I actually like a lot the idea of
a Ldraw-based OpenGL editing/animation* environment with solid export options to
both POVray and a standard format like 3DS. I like it so much I've been dreaming
about it for quite some time now.
Please make it happen ;-)
*I got the animation idea from the following lines found in your site:
Future stuff:
...
robotisize / play window
| | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Miguel Agullo wrote:
> Hi Dan,
>
> This looks very good. Questions/suggestions/comments:
>
> The interface looks like Leocad's one - is that a coincidence?
>
> Please consider exporting to 3DS. Leocad does it, while Mlcad does not.
> Unfortunately, updating Leocad's library is (used to be?) a bit of a pain. This
> would be a great gap to bridge.
>
> Will the camera definition allow adjustments in the Z axis (relative Z axis,
> that is)? Adding that, plus the ability to export it to POVray, would be another
> HUGE plus.
>
> I guess I'm mostly asking for EXPORT options. I actually like a lot the idea of
> a Ldraw-based OpenGL editing/animation* environment with solid export options to
> both POVray and a standard format like 3DS. I like it so much I've been dreaming
> about it for quite some time now.
>
> Please make it happen ;-)
>
>
> *I got the animation idea from the following lines found in your site:
>
> Future stuff:
> ...
> robotisize / play window
1st off thanks for looking.
Second can you post some links to 3DS stuff? I know nothing about it at the
moment. I’m guessing its short for something else.
That request will get tacked on the end of the exports todo list. It will take a
good deal of time before I get round to it. I want to get the editing element of
the program done well before to give it a solid base before I move on to the
exports.
Ah. LeoCAD similarities. Its not original its not plagiarism its that nice in
between artists like to call inspired. I was inspired by the LeoCAD layout.
I have been thinking about animation. It was sparked by holding down the “undo”
button and watching my model spin around. This is a most probably but much later
feature. Animation would be an extension of the robotizise window. Which is
going to be an advanced posturing window. Meaning all the Lego joins would join
and pivot as expected. Ill need to get brick clicking working first but I’m long
way towards that already in version 0.8A. I called it robotisize because it will
use some robotics algorithms used for positioning robot arms.
Camera/view. Version 0.8A has camera rotation about the Y axis. I’m going to add
Z rotation maybe pre-set Z angles. Mainly because I can’t see the bottom of my
models and that makes it hard to build em. Which is bad.
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Daniel Bennett wrote:
> 1st off thanks for looking.
My pleasure
>
> Second can you post some links to 3DS stuff?
3DS stands for 3D Studio, or 3DS Max, as it now is called. This was originally
an Autodesk product, now offered by Discreet.
http://www.discreet.com/3dsmax/
But what I was referring to is the file format, which has become one of the
standard ways to share 3D data between apps. And I was actually just using 3DS
as an example of a file format that, unlike POV or VRML, is oriented towards a
wide range of programs.
http://www.the-labs.com/Blender/3DS-details.html
http://www.spacesimulator.net/tut4_3dsloader.html
http://sourceforge.net/projects/lib3ds/
Info on a bunch of file formats
http://thorkildsen.no/faqsys/cates/formats.html
http://www.dcs.ed.ac.uk/home/mxr/gfx/3d-hi.html
>
> I have been thinking about animation. It was sparked by holding down the “undo”
> button and watching my model spin around. This is a most probably but much later
> feature. Animation would be an extension of the robotizise window. Which is
> going to be an advanced posturing window. Meaning all the Lego joins would join
> and pivot as expected. Ill need to get brick clicking working first but I’m long
> way towards that already in version 0.8A. I called it robotisize because it will
> use some robotics algorithms used for positioning robot arms.
Cool. I'm working on an include file for POVray to animate minifigs. Trust me,
you'll have fun writing that part of the code. Well, at least *testing* it ;-)
>
> Camera/view. Version 0.8A has camera rotation about the Y axis. I’m going to add
> Z rotation maybe pre-set Z angles. Mainly because I can’t see the bottom of my
> models and that makes it hard to build em. Which is bad.
What I miss in most Ldraw apps is a way to freely position the camera. The one
part missing in most is the possibility to move the camera on the relative
Z-axis. That is, away from or into the subject.
Keep it up.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Miguel Agullo wrote:
> What I miss in most Ldraw apps is a way to freely position the camera. The one
> part missing in most is the possibility to move the camera on the relative
> Z-axis. That is, away from or into the subject.
Now that would be the zoom, wouldn't it? What I actually meant was a) a zoom
that can get "inside" a model (useful for buildings specially) and b) a way to
move and rotate the camera's target point.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Miguel Agullo wrote:
> In lugnet.cad, Miguel Agullo wrote:
>
> > What I miss in most Ldraw apps is a way to freely position the camera. The one
> > part missing in most is the possibility to move the camera on the relative
> > Z-axis. That is, away from or into the subject.
>
> Now that would be the zoom, wouldn't it? What I actually meant was a) a zoom
> that can get "inside" a model (useful for buildings specially) and b) a way to
> move and rotate the camera's target point.
I think ldview and ldglite can do this.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Don Heyse wrote:
> In lugnet.cad, Miguel Agullo wrote:
> > In lugnet.cad, Miguel Agullo wrote:
> >
> > > What I miss in most Ldraw apps is a way to freely position the camera. The one
> > > part missing in most is the possibility to move the camera on the relative
> > > Z-axis. That is, away from or into the subject.
> >
> > Now that would be the zoom, wouldn't it? What I actually meant was a) a zoom
> > that can get "inside" a model (useful for buildings specially) and b) a way to
> > move and rotate the camera's target point.
>
> I think ldview and ldglite can do this.
There is a nice little and probably well hiden feature i have added to GLIDE.
Its called "Brick Focus". To use it press the 'F' key. Its will focus the camra
on the curently selected brick. To reset the camera just press 'R'. Its the
easyest way to move the camra in my opinion ala HOMEWORLD.
If you Deselect all the bricks you can then use the brick move keys to move the
camra.
Brick grooping. Ever played an RTS game eg Command & Conquer? Im trying to take
lots of insperation from them. To make a brick groop press ALT and a number key.
Later you can reselect that groop by pressing the number key again. There is
more you can do with grooping its at the bottom of the help file.
Let me know if you like it.
--Dan.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Hi
I don't want to give the user total camera freedom. Sorry. It’s because of RTS
games. I like RTS games there my fave computer game genre. The ones I found
easiest to use had fixed views. If you have full camera control you can get lost
easy.
Having said that I do allow camera movement not rotation in 0.7A. Deselect all
the bricks then press the brick move keys.
I curently have rotation in 0.8A as well but im not shure quite how im going to
alow it to be used yet.
--Dan.
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Daniel Bennett wrote:
> In lugnet.cad, Miguel Agullo wrote:
> > Hi Dan,
> >
> > This looks very good.
Seconded. I particularly like the cartoony renderering, presumably done by
increasing OpenGL's line width and not using lighting? Solve all your
mismatching normal problems by not using them! Genius
> > Please consider exporting to 3DS. Leocad does it, while Mlcad does not.
I've played around with available 3DS importers/exporters for other projects
and usually ended up rolling my own (it's not too hard to do a simple export)
However, lib3ds seems to be the best of the bunch and is something I wish I'd
found 2 years ago. http://lib3ds.sourceforge.net/
> Camera/view. Version 0.8A has camera rotation about the Y axis. I?m • going to add
> Z rotation maybe pre-set Z angles. Mainly because I can?t see the bottom • of my
> models and that makes it hard to build em. Which is bad.
I use a very nice view adjuster called agviewer. Polar Rotations, Flying
mode, zooming panning, etc. Why boggle your mind thinking about gimble
lock (and friends) when Philip Winston has done the hard work already?
Google for it and you get two files agviewer.h agviewer.c.
Here's one http://www.cise.ufl.edu/~lok/teaching/comp136/basic/agviewer.cpp
Send it mouse/keyboard events and it basically jiggers your model view matrix
just before you do your drawing. Simple quick and easy. It's written for glut,
but it's v easy to hack into working on other things. I've done it for X11
Good Luck
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Daniel Bennett wrote:
> Hi.
> Its nowhere near finished or even stable but if you want a look at a work in
> progress.
>
> www.mr-bucket.co.uk/GLIDE/
>
> Since its only in alpha at the moment I'm not really looking for specific this
> doesn't work that's broken replies. I would like to know what you lot think of
> GLIDE so far though, and what features you would like to see added.
> The long time lug neters among you may or may not remember I posted my first
> version about a year ago. Article 10095. I have only just come back to working
> on GLIDE so not a great deal has changed.
> --Dan.
hi Daniel,
I have tested GLIDE 0.7 and i must say it looks promising.
As simple as it is now, the interface seems very effective.
In a more stable and polished state, undoubtly it would be my preferred editor
for small models.
It's difficult to attract users at start, don't give up, GLIDE is a winner
application. Many models are less than 100 bricks and Lego Digital Designer is
arguably a disappointment.
You don't need to include ldraw parts, the ldraw directory is available in the
LDRAWDIR environment variable.
Here are many of my models:
http://membres.lycos.fr/brickcaster/misc/models.zip
Feel free to include some as samples if you wish.
greetings,
- damien
e-mail: damien.guichard@wanadoo.fr
web page 1: http://membres.lycos.fr/brickcaster/
web page 2: http://perso.wanadoo.fr/alphablock/
| | | | | | | | | | | | | | | | | |
Hi All.
Just a few new things for version ALPHA 0.72:
GLIDE Icon, Smooth look lines, camera rotation, mouse brick movement, drag
selection, and EXPLODE.
To rotate and move the camera just deselect all the bricks then use the brick
movement and rotation keys. Brick focus "F" is the most useful camera command.
To move bricks using the mouse hold the right mouse button down after selecting
bricks.
Drag selection currently only half works. Does anyone know a good tutorial/demo
for OpenGL picking?
To make your model explode hold down CTRL + E. My early rotation code did some
very strange things... one of my friends missed being able to blow up my virtual
lego creations you see.
Next version should have clicking bricks and working drag selection.
http://www.mr-bucket.co.uk/GLIDE/
--Dan.
| | | | | | | | | | | | | | | | | |
Hi
The next version is now out. ALPHA 0.73. There have been no big changes. They
should be in the next version.
New stuff:
You can now select bricks by color.
The drag selection now works.
Some brick type tabs have been added.
Next version will be alpha 0.8.
It will have BFC compliance to fix the lighting problems or clicking bricks.
Not decided which to do first yet.
I recon about 3 weeks befor thats out.
--Dan.
| | | | | | | | | | | | | | | | | | | | | |
Hi
Which would you lot like to see first:
Lighting fix, Clicking bricks, or MPD suport?
You can get the curent version from http://www.mr-bucket.co.uk/GLIDE/
--Dan.
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Daniel Bennett wrote:
> Next version will be alpha 0.8.
> It will have BFC compliance to fix the lighting problems or clicking bricks.
> Not decided which to do first yet.
> I recon about 3 weeks befor thats out.
Having written an OpenGL-based LDraw viewer (LDView), I'd like to point out that
you can't rely on parts to contain BFC information. As time goes by, more and
more parts are BFC certified, but many aren't, and many may never be. (I hope
that eventually all will be, but unless there's a concerted effort to update all
the old files, it isn't likely to happen.)
Fortunately, OpenGL has a fairly easy solution to the problem. Just turn on
two-sided lighting when you don't have BFC information. While this does slow
down the rendering somewhat (it varies on different hardware), it nevertheless
gets the job done. It also has the advantage of being really easy, and you can
put off BFC compliance until later.
An alternate solution that works as long as you don't have specular enabled is
to use two directional lights pointing in opposite directions. I found this to
be faster on my nVidia GeForce 3 than enabling two-sided lighting.
--Travis Cobbs
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
Hi
I agree its a shame about the incomplete BFC situation. Currently I use
Two-Sided lighting in GLIDE you don't notice the performance hit because most of
the processing effort is done by the CPU at the moment. That’s what slows it
down rather than the GFX card. My Nvidia TI4200 recently cooked itself and I’m
back on an old TNT2. There is only a small difference in performance between the
two in GLIDE.
Speaking of specular lighting could you point me to a good OGL tutorial for it
because I am unable to get it working currently.
On my todo list is a brick-authoring window. With all sorts of thing to help
brick authors change the winding on facets or add BFC tags. I’m hoping I can get
that working and secondly I’m hoping it becomes popular because it would result
in bricks looking better in GLIDE and other programs. Its low on the todo list
which doesn't mean its not important but does mean it will be a long time before
it gets done.
Thanks for taking an interest.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Dan wrote:
> Hi
> I agree its a shame about the incomplete BFC situation. Currently I use
> Two-Sided lighting in GLIDE you don't notice the performance hit because most of
> the processing effort is done by the CPU at the moment. That’s what slows it
> down rather than the GFX card. My Nvidia TI4200 recently cooked itself and I’m
> back on an old TNT2. There is only a small difference in performance between the
> two in GLIDE.
>
>
That's because most of the focus in Grahics HW the past few years has
been in texture
and shading performance, and *not* in raw polygon drawing that LCAD
makes so much
use of.
We mainly have games to thatnk for that. For the most part (especially
in fast moving
games) it's much easier to add details to a texture on a 'large' flat
polygon than it is
to refine the surfaces insto seperate polygons with seperate textures.
It's easier on
development, and it's easier to get better performance too.
In our world though with oure bricks having many sides, and generally
solid colors,
we don't have many place to use textures. Obviously they'd be useful on
printed parts,
and maybe standardizing the definaition of such things will be done soon
by the
LDraw language standards commitee.
Till the Hardware Polygon speed improves, the easiest thing to do is to
try to
figure out which polygons in a model (not necc. a brick) will never,
ever, be
seen and cull them as early as possible.
-Kyle
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Kyle McDonald wrote:
> Dan wrote:
>
> > Hi
> > I agree its a shame about the incomplete BFC situation. Currently I use
> > Two-Sided lighting in GLIDE you don't notice the performance hit because most of
> > the processing effort is done by the CPU at the moment. That’s what slows it
> > down rather than the GFX card. My Nvidia TI4200 recently cooked itself and I’m
> > back on an old TNT2. There is only a small difference in performance between the
> > two in GLIDE.
> >
> >
> That's because most of the focus in Grahics HW the past few years has
> been in texture
> and shading performance, and *not* in raw polygon drawing that LCAD
> makes so much
> use of.
This is only true to a point. As long as you have a reasonably modern video
card, its on-board geometry performance is going to far exceed the geometry
performance you could get out of the fastest CPU. I don't know how GLIDE does
its drawing, but I do know that a TI 4200 should be quite a bit faster than a
TNT2 simply because the TNT2 doesn't have on-board T&L (transform and lighting)
support.
I measured LDView on a GeForce 3 at about 15 million vertices per second. It
should do quite a bit more on a TI 4200. I'm not sure what a 3.4GHz CPU is
capable of, but I'd be very surprised if it matched the TI 4200. When I first
got my GeForce 3, it was an upgrade from a TNT2. LDView performance on a 1GHz
PIII went up by a factor of 8-10.
> We mainly have games to thatnk for that. For the most part (especially
> in fast moving
> games) it's much easier to add details to a texture on a 'large' flat
> polygon than it is
> to refine the surfaces insto seperate polygons with seperate textures.
> It's easier on
> development, and it's easier to get better performance too.
>
> In our world though with oure bricks having many sides, and generally
> solid colors,
> we don't have many place to use textures. Obviously they'd be useful on
> printed parts,
> and maybe standardizing the definaition of such things will be done soon
> by the
> LDraw language standards commitee.
>
> Till the Hardware Polygon speed improves, the easiest thing to do is to
> try to
> figure out which polygons in a model (not necc. a brick) will never,
> ever, be
> seen and cull them as early as possible.
Take a look at the specs of modern graphics cards, and you will see that they
have done a very good job of keeping the geometry performance up with
improvements in texturing and fill-rate. IIRC, a GeForce 3 was rated at around
25-30 million vertices per second. By comparison, the GeForce FX 5950 Ultra is
rated at 356 million vertices per second. And even though both those numbers
are marketing numbers, it seems likely they were derived in a similar manner,
and have gone up by a factor of 10 in two generations. (GeForce FX is basically
GeForce 5.)
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> because most of the processing effort is done by the CPU at the moment.
Possibly not the best way I could have worded it. GLIDE in its current form is
inefficient. There is some redundant sorting and a lot of list iteration that
the CPU does before it calls on OGL. This is the main speed-limiting factor.
With GLIDE as it is, a faster CPU and memory will make a bigger difference to
performance than a better GFX card.
I am aiming to create a feature rich program with a very friendly useable
interface. I can refactor / optimise after I have the features in there. A lot
of this is a learning process for me as this is my first OpenGL program. As such
I am creating solutions to problems that are not always optimal. In other cases
I have been lazy for the sake of development speed. Once a piece of code works
correctly making it go faster drops to the bottom of my todo pile. For example I
have some bubble sorts scattered around ware insertion sorts would be a far
better solution. In my opinion there is much more fun code to be written than
optimised sorts, like the (fun but pointless) explode model code “CRTL + E”.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
> > Just turn on two-sided lighting when you don't have BFC information.
> Currently I use Two-Sided lighting in GLIDE
Hi
Actually I only thought I was using two-sided lighting. Turned out I had the
code commented out which is why the lighting was a bit awry. Thanks for pointing
it out.
--Dan.
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Daniel Bennett wrote:
> Hi
> The next version is now out. ALPHA 0.73. There have been no big changes. They
> should be in the next version.
>
> New stuff:
> You can now select bricks by color.
> The drag selection now works.
> Some brick type tabs have been added.
>
> Next version will be alpha 0.8.
> It will have BFC compliance to fix the lighting problems or clicking bricks.
> Not decided which to do first yet.
> I recon about 3 weeks befor thats out.
>
> --Dan.
Oh and you can rotate the bricks using shift + the right mouse button.
It allows you to do rotation with finer granularity than 1 degree unlike the
rotation key presses.
| | | | | | | | | | | | | | | | | | |
Hi
Glide has been on hold now for about a month but its back in development. You
can look forward to clicking bricks in about two to three weeks.
Once I have the system implemented is there anyone out there who would be
prepared to start writing click files for parts?
It would be my own standard not officially accepted by anyone so the work may
never see the light of generally accepted day.
To see the standard so far take a look at:
http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
I don’t want any files yet I just want to know if there are people out there
prepared to do a few clicks.
--Dan.
| | | | | | | | | | | | | | | | | | | | |
On Tue, Jun 22, 2004 at 01:40:04PM +0000, Dan wrote:
> To see the standard so far take a look at:
>
> http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
Should the format perhaps be changed so that LCD info could be included
inline in a valid DAT file? Perhaps make all the lines start with a "0
LCD" before anything else? Then, when reading a DAT file, a program can
recognize and parse LCD info, in addition to looking for the .lcd file.
Does that make sense? Do you think it's worth the effort?
I think connection data is really cool, and we should try to make it
part of the standard library.
--
Dan Boger
dan@peeron.com
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
The it would be slick to have the LCD info in the dat file, but
it might complicate issues being dicussed by the Ldraw committee : (
It seems that pov style includes aren't allowd in official files either
so maybe keeping it seperate for a while will be easier...
I'd be willing to take a stab at writing some "click" files : )
Actually, I was thinking of writing a quick vb app that parsed dat files
and automatically genrates LCD info for parts that have stud and tube
primitives. I bet that'd save a lot of time.
LMKWYT
-JSM
Dan Boger wrote:
> On Tue, Jun 22, 2004 at 01:40:04PM +0000, Dan wrote:
>
> > To see the standard so far take a look at:
> >
> > http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
>
>
> Should the format perhaps be changed so that LCD info could be included
> inline in a valid DAT file? Perhaps make all the lines start with a "0
> LCD" before anything else? Then, when reading a DAT file, a program can
> recognize and parse LCD info, in addition to looking for the .lcd file.
>
> Does that make sense? Do you think it's worth the effort?
>
> I think connection data is really cool, and we should try to make it
> part of the standard library.
>
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
On Tue, Jun 22, 2004 at 04:17:29PM +0000, Xanthra47 wrote:
> The it would be slick to have the LCD info in the dat file, but it
> might complicate issues being dicussed by the Ldraw committee : ( It
> seems that pov style includes aren't allowd in official files either
> so maybe keeping it seperate for a while will be easier...
There's a difference between supporting POV inline (which is not
controlled in the community) and supporting LCD info (which could be
integrated into the DAT format). I'd like to see programs support both
options - both as an external .lcd file, and as inline lcd info in the
.dat.
> I'd be willing to take a stab at writing some "click" files : )
> Actually, I was thinking of writing a quick vb app that parsed dat
> files and automatically genrates LCD info for parts that have stud and
> tube primitives. I bet that'd save a lot of time.
That's a great idea! Though, and I might be confused here, wouldn't it
be possible to just create a stud.lcd file, and as the stud.dat file in
included, the lcd info would automagically be there?
--
Dan Boger
dan@peeron.com
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Dan Boger wrote:
> There's a difference between supporting POV inline (which is not
> controlled in the community) and supporting LCD info (which could be
> integrated into the DAT format). I'd like to see programs support both
> options - both as an external .lcd file, and as inline lcd info in the
> .dat.
I agree, but in the short term, I think seperate files may be simpler.
> That's a great idea! Though, and I might be confused here, wouldn't it
> be possible to just create a stud.lcd file, and as the stud.dat file in
> included, the lcd info would automagically be there?
I thought so too, but the format document (way at the bottom) implies
that this might be undesirable. I'm not sure I understand why, though : (
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> > That's a great idea! Though, and I might be confused here, wouldn't it
> > be possible to just create a stud.lcd file, and as the stud.dat file in
> > included, the lcd info would automagically be there?
>
> I thought so too, but the format document (way at the bottom) implies
> that this might be undesirable. I'm not sure I understand why, though : (
I do indeed think it would be undesirable. As we all know Stud.dat gets used
every ware. There are a fair few instances were the clicking behaviours of two
bricks would be different even though they are both referencing the same
stud.dat file for geometry.
For example parts 3822 and 3622. A door and a brick respectively. The studs on
the brick snap every 90 degrees but on the door you often want it open to say
45degrees. So there are two different behaviours for stud.dat in this case. If
you inherited clicking information from sub parts of the geometry of a brick,
you would need to keep track of all the different ways that sub part can be
used. This would make things much more complicated.
The use of sub parts and primitives is a very elegant way of representing
geometry for Lego bricks. I think the same solution can be applied to clicks.
I propose that instead of inheriting from sub parts click authors can use a
library of sub clicks. The same way primitives like stud.dat are used for the
geometry of bricks.
To sum up. There would be a stud.lcf but it would not be referenced from
stud.dat.
The latest GLIDE download has a few .lcf files included with it. I recommend
taking a look at these. It shows a bit of file reuse for stud and stud inlet
pairs.
--Dan.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
I guess I'm thinking about this differently. It's not that the
individual studs on the brick don't allow other mating angles. (IE you
can place a 1 x 6 technic plate with rounded ends on any single stud at
some funcky angles) It's the combination of the contraints imposed by at
least 3 studs in a non-linear arangement that results in the 90 degree
"snaps" in that plane. Just like 2 studs limits one to 180 degree snaps.
It's even worse than that. It's the number of studs that are actually
being used, not count of stud primitive on the element, that determines
how things behave. Try putting some 1x1 round plates (dots) in between
some bricks and you'll see what I mean. With just 1 dot you can orient
the 2xN bricks at any angle. We need to allow for things like that so
any stud primitive, where ever it is used, should always allow aribrary
angles...
Dan wrote:
> I do indeed think it would be undesirable. As we all know Stud.dat gets used
> every ware. There are a fair few instances were the clicking behaviours of two
> bricks would be different even though they are both referencing the same
> stud.dat file for geometry.
>
> For example parts 3822 and 3622. A door and a brick respectively. The studs on
> the brick snap every 90 degrees but on the door you often want it open to say
> 45degrees. So there are two different behaviours for stud.dat in this case. If
> you inherited clicking information from sub parts of the geometry of a brick,
> you would need to keep track of all the different ways that sub part can be
> used. This would make things much more complicated.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Jason S. Mantor wrote:
> I guess I'm thinking about this differently. It's not that the
> individual studs on the brick don't allow other mating angles. (IE you
> can place a 1 x 6 technic plate with rounded ends on any single stud at
> some funcky angles) It's the combination of the contraints imposed by at
> least 3 studs in a non-linear arangement that results in the 90 degree
> "snaps" in that plane. Just like 2 studs limits one to 180 degree snaps.
> It's even worse than that. It's the number of studs that are actually
> being used, not count of stud primitive on the element, that determines
> how things behave. Try putting some 1x1 round plates (dots) in between
> some bricks and you'll see what I mean. With just 1 dot you can orient
> the 2xN bricks at any angle. We need to allow for things like that so
> any stud primitive, where ever it is used, should always allow aribrary
> angles...
Note also that a 1x4 brick can be attached to a 2x4 brick anywhere on about
70-80 degree angle if only attached by the end stud - its only the other studs
hitting the sides that restrict it.
ROSCO
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Jason S. Mantor wrote:
> I guess I'm thinking about this differently. It's not that the
> individual studs on the brick don't allow other mating angles. (IE you
> can place a 1 x 6 technic plate with rounded ends on any single stud at
> some funcky angles) It's the combination of the contraints imposed by at
> least 3 studs in a non-linear arangement that results in the 90 degree
> "snaps" in that plane. Just like 2 studs limits one to 180 degree snaps.
> It's even worse than that. It's the number of studs that are actually
> being used, not count of stud primitive on the element, that determines
> how things behave. Try putting some 1x1 round plates (dots) in between
> some bricks and you'll see what I mean. With just 1 dot you can orient
> the 2xN bricks at any angle. We need to allow for things like that so
> any stud primitive, where ever it is used, should always allow aribrary
> angles...
I have tried to accommodate these sorts of behaviours in two ways:
Priority and override.
If two parts have different behaviours like a "dot" and a "Brick" the one that
is moved to form the connection is the one that takes priority. If you move a
dot connected to a plate with the dot as the primary selection (Pink highlights
in glide) then the connection angles are taken from the dot. Which is freely
rotating. Thus allowing lots of angles between the brick and plate.
Override is much simpler. The maximum and minimum rotations are ignored, as are
the locking angles. The click simply rotates freely about its axis. This is to
allow for more creative use of brick arrangements.
I believe clicking should be an aid to creating LDraw models with out being
restrictive.
so
> We need to allow for things like that so
> any stud primitive, where ever it is used, should always allow arbitrary
> angles...
Hopefully this should be possible.
The real test is going to be what people think of it once the first version of
GLIDE with clicking is released.
--Dan.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
I should point out that priority and override are features of GLIDE and are not
explicitly specified in the format.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Jason S. Mantor wrote:
> it would be slick to have the LCD info in the dat file, but
> it might complicate issues being dicussed by the Ldraw committee : (
> It seems that pov style includes aren't allowd in official files either
> so maybe keeping it seperate for a while will be easier...
I really like the way the .dat format reuses geometry e.g. stud.dat. I think the
clicking format should be able to do the same thing. I imagine that would be
quite a bit more difficult to reuse if the clicking info was in the dat files.
> Actually, I was thinking of writing a quick vb app that parsed dat files
> and automatically genrates LCD info for parts that have stud and tube
> primitives. I bet that'd save a lot of time.
That’s a cracking idea. (In my part of the world cracking means good by the
way.) I imagine that it would still need some human input, as detecting ware
stud inlets are would be extremely difficult. But that program would certainly
make it a lot easier to start with. You wouldn't have to write all the clicks
from scratch just some of them.
--Dan.
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad, Dan Boger wrote:
> On Tue, Jun 22, 2004 at 01:40:04PM +0000, Dan wrote:
> > To see the standard so far take a look at:
> >
> > http://www.mr-bucket.co.uk/GLIDE/LCD_File_Format.html
>
> Should the format perhaps be changed so that LCD info could be included
> inline in a valid DAT file? Perhaps make all the lines start with a "0
> LCD" before anything else? Then, when reading a DAT file, a program can
> recognize and parse LCD info, in addition to looking for the .lcd file.
>
> Does that make sense? Do you think it's worth the effort?
>
> I think connection data is really cool, and we should try to make it
> part of the standard library.
Long-term, making connection data a part of the library would be awesome.
Short-term, getting a working implementation should be the focus.
Dan (Bennett) - would you like some publicity for GLIDE and click authors on
LDraw.org? I can't spare the moments to write it up (just caught this thread on
the way to bed 2.5hrs late), but if you or someone else can, and pass the
article to Orion or myself, we'll certainly post it. A short news article with a
cool introduction, the appropriate links, and maybe a screenshot or two would be
great. That way your project can gain exposure from people who visit LDraw.org
for news and reference.
I'm excited the LCD proposal is being implemented! Great work, I can't wait to
try this out with the next GLIDE release.
Email me if you have any questions.
-Tim
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad, Tim Courtney wrote:
> A short news article with a
> cool introduction, the appropriate links, and maybe a screenshot or two would be
> great.
Not just yet please... I’d like to get clicking working first before GLIDE gets
announced to the world at large. Unfortunately experience tells me that my time
estimates on programming are always a bit optimistic. I "think" I will be able
to get it done within a month. I'll let you know.
--Dan.
| | | | | | | | | | | | | | | | | |
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.
| | | | | | | | | | | | | | | | |
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
| | | | | | |
