Introduction
On 03/23/2016 03:52 PM, jpmendes wrote:
Maybe I'm wrong but I'm not enthusiastic about the use of sliders on the UI.
I would prefer a direct entry of values or both options. Since we do not
have real variables, each time you move a slider the script is recompiled to
reflect the actual state, when the project gets complicated the lag will be
not negligible if not insupportable. And not everybody have top speed
machines.
Right, the ability to enter the value directly can be useful for
different reasons. I hate it if sliders prevent it to enter a nice
value and always end up producing 19.9 or 20.1.
Thinking about that it might not even be a good idea to always
force the representation the script suggests, giving the user
some kind of toggle to change the display style could solve
this (at the expense of more complex UI elements, but that's
probably not too big a problem).
The update is a separate topic though, there is no need to always
directly update for every change. This can be easily covered by a
small delay that causes recalculation only after the user stops
changing the values.
In addition, I think there should be also a simple checkbox (or
some other means) that will control if the automatic update
happens at all.
With direct entree boxes you could define ranges for the parameters
and observe the respective evolution result.
Can you illustrate that a bit more? I'm not sure how those ranges
would work. I'm somehow reminded at the animation behavior, but
that seems too complicated with multiple parameters.
ciao,
Torsten.
On Mar 23, 2016 7:49 PM, "Torsten Paul" Torsten.Paul@gmx.de wrote:
The Milestones part could use some more details. I know it's
not easy to give a very detailed plan for this type of project
with a number of unknowns that will only become clear in the
first phase. So one option to get the steps a bit clearer
could be to explain how you want to approach the different
parts of the project.
So what I mean is basically the first part of the proposal
list some things to do with "We can...", the milestone part
should outline the (small) steps that say how it will be
possible to decide what will be done, ideally on a weekly
basis.
I will try to make milestone section better.
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
After reading the Amarjeet Singh's proposal I have to recognize that it is
has more features than I thought. The manual entry of parameters is planned
and ranges are too.
Well, relative on how the ranges could work within the UI, I'm seeing a kind
of animation without the use of $t. Each time we start a new compilation the
UI exported variables increment / decrement by it's own associated step. Of
course I have no idea on how this could be done internally, but Amarjeet
surely knows how to solve the problem.
Thanks Amarjeet for your enthusiasm and contribution.
jpmendes
--
View this message in context: http://forum.openscad.org/Introduction-tp16322p16693.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 23 March 2016 at 19:47, Torsten Paul Torsten.Paul@gmx.de wrote:
Thanks. Just a quick first response...
The detailed description already has some good points and
lists examples for the topics we discussed. That looks
like a good base for approaching the project and defining
the specific things to do.
The Milestones part could use some more details. I know it's
not easy to give a very detailed plan for this type of project
with a number of unknowns that will only become clear in the
first phase. So one option to get the steps a bit clearer
could be to explain how you want to approach the different
parts of the project.
So what I mean is basically the first part of the proposal
list some things to do with "We can...", the milestone part
should outline the (small) steps that say how it will be
possible to decide what will be done, ideally on a weekly
basis.
I have edited milestones and I found a issue in working of parameter
feature and added it in project details.
@all
Please, review it.
https://docs.google.com/document/d/1hXXQI0PEPQnu6e-x0huNQsMt_3Ocn8aBtpwJ_0C-uiM/edit#
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"knowledge about knowledge is power"
On 24 March 2016 at 03:12, jpmendes jpmendes54@gmail.com wrote:
After reading the Amarjeet Singh's proposal I have to recognize that it is
has more features than I thought. The manual entry of parameters is planned
and ranges are too.
Well, relative on how the ranges could work within the UI, I'm seeing a kind
of animation without the use of $t. Each time we start a new compilation the
UI exported variables increment / decrement by it's own associated step. Of
course I have no idea on how this could be done internally, but Amarjeet
surely knows how to solve the problem.
Thanks Amarjeet for your enthusiasm and contribution.
Thanks @jpmendes for your valuable views and these have seriously
increased my morale.
But what I proposed regarding the step was not what you are suggesting
I was justing step attribute like step attribute in HTML input tag
which give the minimum possible change in the value that can take
place by default it is 1.
And what you are suggesting can also be done. Just want to get views
of my mentor on this feature @Torsten Paul and @Marius Kintel
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"knowledge about knowledge is power"
On Mar 24, 2016, at 02:17 AM, Amarjeet Kapoor amarjeet.kapoor1@gmail.com wrote:
Please, review it.
https://docs.google.com/document/d/1hXXQI0PEPQnu6e-x0huNQsMt_3Ocn8aBtpwJ_0C-uiM/edit#
The proposal looks decent.
Two things to keep in mind (from my perspective):
-
A lot of time spent on this project would be how to design the language front-end for allowing specifying parameter, not just the GUI. I would allocate significant time towards those efforts, especially since that involves community involvement. It’s not 100% clear from the proposal how this will be handled. Torsten did write an original patch as an example for how to do this, but since then there has been significant community discussion. I assume you know the overview page at https://github.com/openscad/openscad/wiki/Meta-Data-Use-Cases. We should probably link the forum discussions there too.
-
A key factor for a successful application is to demonstrate skills and ability to deliver working code. I would strongly suggest working with the source code in order to demonstrate this by either fixing bugs, refactoring code, adding features or improving documentation.
Kind Regards,
-Marius
Some thoughts about the future UI or future functionality developments ...
Torsten asked me to better explain my understanding of ranges concerning the
UI.
As the thread name is "Introduction", let me introduce myself since I'm
posting on the forum for sometime and never did that.
I'm a humble regular OpenSCAD user, not part of development team. I'm in
Portugal and many many years ago when Bill Gates was starting programming I
made my incursion on the software world, programming a couple of things,
first directly in machine code of the 8085, 6800 and 6502. Soon after,
started programming in Assembly of those 3 processors and also the 6809. In
that time I was crazy about the new 6809 possibilities. A couple of years
after I experienced programming in Forth. I implemented the core of Forth
for the 6809, based on a 8085 version made available by the Forth Group, and
and a very minimal OS around the Forth language. 20 years after I had a 2
year experience with VHDL and hardware synthesis using the Altera and
Xilinx IDE's. From then on another 20 years have passed and I never
programmed again. Now I'm retired and I'm starting once more. Memory and
speed thinking are not as good as used to be, but I will manage that as well
as I can.
I'm falling with love with OpenSCAD despite some language limitations namely
in what concerns to the memory of things. Although real variables do not
exist in the language we could have "memory" if we could write to and and
read from a file. However there are a strong opposition to this inside the
OpenSCAD development team. Loging onto a file would be a good thing. Good
animation, for instance, is related with state machines and state machines
need "memory".
Now about the UI... Maybe, as the UI is a piece of software independent from
the language one could compensate the lack of "memory" of the language
introducing some "memory" in the UI. If some variables can be "exported" to
the UI for better user interaction with the script, maybe we can "export" an
event as well. Example: two objects moving touch each other. If this event
is passed to the UI and the UI (maybe a plugin) retains it's memory, it may
trigger a different evolution in the objects behavior until a new event
occurs.
From my VHDL times I remember that an entity was assign a structural
architecture and a behavioral architecture. Maybe we could have something
similar to "behavioral architecture" without stop being backward compatible,
by "exporting" some variables to different destinations.
The destinations would be the UI or future plugins. The UI or the plugins
would recognize them and would return results as UI.var or plugin.var
variables.
Lets see...
Exporting...
@UI.var_1(range_1) ... @UI.var_n(range_n)
the UI would return:
UI.var_1 ... UI.var_n (values in the respective ranges)
and for backward compatibility we would assign:
var_1=UI.var_1 ... var_n=UI.var_n
Same procedure for the plugins.
About events, something like:
when(event_expression){
@plugin1.event_a
@plugin2.event_a }
Plugins had received previously the exported variables with the ranges on
which they should act in case of "event_a", or when "event_a" occurs,
plugins will call their own resources accordingly, sound for instance.
Then the UI will be more a kind of IDE with a built in simulator. And maybe
this is not the direction to follow, I don't know. I'm only delivering an
idea.
Obviously there are two ways of seeing things: statically and dynamically.
On the static way the user introduces the values using the UI widgets and
then compile. On the dynamic way we will have an internal clock, we already
have the $t, to put things moving. One can say this is of no great use since
each recompilation takes too much time and we loose the sensation of
continuity. Well.. with this process better animations and some interaction
with external world can be accomplished. Imagine I've made the parts of a a
humanoid robot and I want to animate it and made it to act accordingly to my
voice commands...
Of course if one wants to see how a geometrically complex object deforms,
maybe the frame rate will be too low for direct observation.
Also one could make a script where the objects are created, and another
where they are assembled from previously exported .STL files. In the
assembly script one could define the interactions between objects and assign
some physical qualities color, mass, speed, sound, that would be passed to
the plugins for proper treatment. There are obvious limitations: if a rubber
ball collides with a iron one maybe we cannot observe the deformation of the
rubber ball from previous loaded STL's. Always some trends have to exist.
And that's my humble contribution for now. Don't laugh too much of the old
man.
Initially I thought to start a new thread with this thoughts, however I
started thinking to myself whether posting this would have some utility
other than making you loose your precious time. So guys please tell me if
you prefer not to hear from me in such domains. No bad feelings at all.
jpmendes
--
View this message in context: http://forum.openscad.org/Introduction-tp16322p16712.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@jpmendes: You've posted several times and raised a number of issues. I'm
just going to respond about one thing, which is the performance of
animation.
"Maybe I'm wrong but I'm not enthusiastic about the use of sliders on the
UI.
I would prefer a direct entry of values or both options. Since we do not
have real variables, each time you move a slider the script is recompiled to
reflect the actual state, when the project gets complicated the lag will be
not negligible if not insupportable. And not everybody have top speed
machines."
I think the big issue here is the slowness of animation, which is partly a
problem with our current implementation, and partly an inescapable
consequence of specifying geometric figures using a programming language.
There is some talk about "real variables" and "compilation" which is maybe
based on a misunderstanding about how OpenSCAD is implemented. What I can
say is that:
-
Adding a new language feature, "real variables", will not speed up
animation under our current implementation. The language design itself is
not at fault, it's the implementation. -
The current implementation doesn't have anything that I would call a
compiler. The language manual states "Variables are set at compile time,
not run-time". That is completely false and misleading, and it screwed me
up for about a year before I started to figure out how OpenSCAD actually
works. The truth is that scripts are processed in three phases. First,
there is a parser, which converts text into a parse tree. Then there is an
evaluator, which evaluates the parse tree and constructs a CSG tree. Then
there is a rendering phase (F5 or F6), which converts the CSG tree into a
3D graphical display. Variables are set at evaluation time. If there is a
compile phase at all, then it's the parser, and variables are not set
during parsing.
I do have ideas on how to significantly speed up animation (which includes
speeding up Customizer GUI animation), but it's not a simple, incremental
change. It involves replacing the current evaluator and F5 preview code. In
other words, it's a big change that shouldn't be allowed to block progress
on the Customizer GUI.
We could tweak the current implementation so that we don't rerun the parser
for each animation frame. Instead, we just re-evaluate the parse tree with
different values of $t (normal animation) or different values of the
variable being tweaked by the customizer GUI. I'm not sure how much this
will help, since the parser probably does a trivial amount of work in most
cases, but we could perform some measurements to see.
Also, it is the nature of OpenSCAD that there will always be scripts that
preview and animate very slowly. There's no way to restrict the language or
fix the implementation to guarantee fast preview and fast animation in all
cases. Even if we make animation 100x faster (which I think is possible),
then a script that currently takes 1 hour to preview, will now preview in
36 seconds, which still means an animation rate of 1 frame per 36 seconds.
Therefore, we have to design the Customizer GUI around the assumption that
some scripts will animate very slowly.
On 24 March 2016 at 15:16, jpmendes jpmendes54@gmail.com wrote:
Some thoughts about the future UI or future functionality developments ...
Torsten asked me to better explain my understanding of ranges concerning
the
UI.
As the thread name is "Introduction", let me introduce myself since I'm
posting on the forum for sometime and never did that.
I'm a humble regular OpenSCAD user, not part of development team. I'm in
Portugal and many many years ago when Bill Gates was starting programming I
made my incursion on the software world, programming a couple of things,
first directly in machine code of the 8085, 6800 and 6502. Soon after,
started programming in Assembly of those 3 processors and also the 6809. In
that time I was crazy about the new 6809 possibilities. A couple of years
after I experienced programming in Forth. I implemented the core of Forth
for the 6809, based on a 8085 version made available by the Forth Group,
and
and a very minimal OS around the Forth language. 20 years after I had a 2
year experience with VHDL and hardware synthesis using the Altera and
Xilinx IDE's. From then on another 20 years have passed and I never
programmed again. Now I'm retired and I'm starting once more. Memory and
speed thinking are not as good as used to be, but I will manage that as
well
as I can.
I'm falling with love with OpenSCAD despite some language limitations
namely
in what concerns to the memory of things. Although real variables do not
exist in the language we could have "memory" if we could write to and and
read from a file. However there are a strong opposition to this inside the
OpenSCAD development team. Loging onto a file would be a good thing. Good
animation, for instance, is related with state machines and state machines
need "memory".
Now about the UI... Maybe, as the UI is a piece of software independent
from
the language one could compensate the lack of "memory" of the language
introducing some "memory" in the UI. If some variables can be "exported" to
the UI for better user interaction with the script, maybe we can "export"
an
event as well. Example: two objects moving touch each other. If this event
is passed to the UI and the UI (maybe a plugin) retains it's memory, it may
trigger a different evolution in the objects behavior until a new event
occurs.
From my VHDL times I remember that an entity was assign a structural
architecture and a behavioral architecture. Maybe we could have something
similar to "behavioral architecture" without stop being backward
compatible,
by "exporting" some variables to different destinations.
The destinations would be the UI or future plugins. The UI or the plugins
would recognize them and would return results as UI.var or plugin.var
variables.
Lets see...
Exporting...
@UI.var_1(range_1) ... @UI.var_n(range_n)
the UI would return:
UI.var_1 ... UI.var_n (values in the respective ranges)
and for backward compatibility we would assign:
var_1=UI.var_1 ... var_n=UI.var_n
Same procedure for the plugins.
About events, something like:
when(event_expression){
@plugin1.event_a
@plugin2.event_a }
Plugins had received previously the exported variables with the ranges on
which they should act in case of "event_a", or when "event_a" occurs,
plugins will call their own resources accordingly, sound for instance.
Then the UI will be more a kind of IDE with a built in simulator. And
maybe
this is not the direction to follow, I don't know. I'm only delivering an
idea.
Obviously there are two ways of seeing things: statically and dynamically.
On the static way the user introduces the values using the UI widgets and
then compile. On the dynamic way we will have an internal clock, we already
have the $t, to put things moving. One can say this is of no great use
since
each recompilation takes too much time and we loose the sensation of
continuity. Well.. with this process better animations and some interaction
with external world can be accomplished. Imagine I've made the parts of a a
humanoid robot and I want to animate it and made it to act accordingly to
my
voice commands...
Of course if one wants to see how a geometrically complex object deforms,
maybe the frame rate will be too low for direct observation.
Also one could make a script where the objects are created, and another
where they are assembled from previously exported .STL files. In the
assembly script one could define the interactions between objects and
assign
some physical qualities color, mass, speed, sound, that would be passed to
the plugins for proper treatment. There are obvious limitations: if a
rubber
ball collides with a iron one maybe we cannot observe the deformation of
the
rubber ball from previous loaded STL's. Always some trends have to exist.
And that's my humble contribution for now. Don't laugh too much of the old
man.
Initially I thought to start a new thread with this thoughts, however I
started thinking to myself whether posting this would have some utility
other than making you loose your precious time. So guys please tell me if
you prefer not to hear from me in such domains. No bad feelings at all.
jpmendes
--
View this message in context:
http://forum.openscad.org/Introduction-tp16322p16712.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 24 March 2016 at 21:47, Marius Kintel marius@kintel.net wrote:
On Mar 24, 2016, at 02:17 AM, Amarjeet Kapoor amarjeet.kapoor1@gmail.com wrote:
Please, review it.
https://docs.google.com/document/d/1hXXQI0PEPQnu6e-x0huNQsMt_3Ocn8aBtpwJ_0C-uiM/edit#
The proposal looks decent.
Two things to keep in mind (from my perspective):
- A lot of time spent on this project would be how to design the language front-end for allowing specifying parameter, not just the GUI. I would allocate significant time towards those efforts, especially since that involves community involvement. It’s not 100% clear from the proposal how this will be handled. Torsten did write an original patch as an example for how to do this, but since then there has been significant community discussion. I assume you know the overview page at https://github.com/openscad/openscad/wiki/Meta-Data-Use-Cases. We should probably link the forum discussions there too.
I have consider that aspect. That's why I have chosen prototyping
model: making a prototype, then getting community feedback and at last
finalizing the code. Yes, I agree in milestones I might not have
allocated enough time on language design I will change that a little.
- A key factor for a successful application is to demonstrate skills and ability to deliver working code. I would strongly suggest working with the source code in order to demonstrate this by either fixing bugs, refactoring code, adding features or improving documentation.
I will start working of patch after submitting the proposal today.
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"knowledge about knowledge is power"