Editing User:Mafm

From BRL-CAD

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 25: Line 25:
  
 
= ToDo =
 
= ToDo =
 
== To finish GSoC ==
 
 
<pre>
 
[2008-07-25 17:01:58]
 
<brlcad> okay, so requirements
 
<brlcad> hooking in to the back-end in *some* fashion is definitely one to do so
 
you can display real stuff
 
<brlcad> libged has enough for that to be doable now, but your app isn't
 
supposed to talk to libged directly, it's a bad coupling
 
<mafm> so I could introduce a class simulating network layer?
 
<brlcad> *delete* *delete* *delete*  .. heh, yes
 
<brlcad> doesn't even have to simulate it, on the app side it could be a network
 
layer using libpkg, but then you'll need to stuf in a server layer that
 
minimally hooks into libged too
 
<brlcad> you could do it without the network communication, but the danger there
 
will be that it really needs to avoid polluting any data types across into the
 
front end
 
<mafm> yes, I mean that the app could call this layer, and this layer bind
 
directly to libged
 
<mafm> and when the network libs are complete, to use them instead
 
<mafm> but the rest of the front-end wouldn't be affected
 
<brlcad> okay, so that sounds like the start of a plan
 
 
 
<brlcad> the other bit I'd like to get a better feel for before gsoc ends is
 
rbgui customization
 
<brlcad> i.e. how easy it is to 1) customize the appearance (theme it or
 
otherwise change how it looks) and 2) add a new control widget (e.g. say you
 
want a rotating progress indicator)
 
<brlcad> if that's a huge deal, then rbgui probably isn't a good framework to go
 
with since the design requirements require a lot of custom interactions and
 
appearance
 
<brlcad> somewhere in there is how layout can be controlled too
 
<mafm> rotating progress indicator?
 
<mafm> the camera coordinates at the moment?
 
<brlcad> finally, the last item making sure input controls are "done" .. not
 
just 90% -- I can redo the entire build system really easily if needed, I can
 
redo the libged binding easily, can work on logging/console, etc .. but there's
 
a higher 'expense' to follow how input control works so that part should be near
 
"done" for the two styles
 
<mafm> I have been working in something like that (as a window with components,
 
not a new widget), but I scraped it because in IOE it doesn't seem to be place
 
for smallish, floating windows
 
<brlcad> that's because it shouldn't be a smallish floating "window" .. it
 
should be a control that can go onto a given context
 
<brlcad> just as an example, say you wanted to draw a simple spinner progress
 
indicator, like http://www.tmssoftware.com/Images/acp.png down on one of the
 
buttons or on the top status bar or elsewhere
 
<brlcad> i'm not saying do that particular control, but need to be able to
 
evaluate how hard it is to write new controls (so maybe try that one)
 
<mafm> contexts are minimum half of the window size?
 
<brlcad> i have a fairly straight-forward sense for how hard that is roughly
 
with cegui, for example
 
<brlcad> little to no idea how hard that will be for rbgui
 
<brlcad> hm? minimum half? (no)
 
<mafm> in example in IOE, when dragging parts of the greeting card
 
<mafm> one context was the sheet for the card, another half was the things to
 
put in there (would be like primitives in our case)
 
<mafm> IIRC :D
 
<brlcad> yeah, that was a separate (temporary) context/panel
 
<brlcad> how much space those take up is content-specific and
 
application-specific
 
<brlcad> but yeah, could hold primitives in our case
 
 
 
<brlcad> the last bit I'd add would be to actually do a binary release
 
<brlcad> for at least one platform
 
<brlcad> for developers
 
<brlcad> (to check it out)
 
[2008-07-25 17:44:33]
 
</pre>
 
 
== About building system ==
 
  
 
<pre>[2008-07-01 20:30:08]
 
<pre>[2008-07-01 20:30:08]
Line 166: Line 92:
  
 
= Log =
 
= Log =
 
== August ==
 
 
August 24:
 
* Submitting final evaluation survey, and sending e-mail to the developer mailing list with the summary about the work done and future.
 
* Screenshot: http://brlcad.org/~mafm/g3d-screenshots/brlcad_rbgui_20080824-1.png
 
 
August 20:
 
* (In trunk) Bug fixing: not using argv[0] when argc<1, it tends to be crashy ;) (it happened to me when trying to use the library). I did some minor normalization in other commands, initializing the result and so on, hopefully I didn't introduce new bugs due to poor understanding of the way it works.
 
* (In trunk) Remove '#if GED_USE_RUN_RT', Sean did the same yesterday in libged but not here, so now it won't compile.
 
* Fixing the commands in g3d using libged -- finally they are using the library correctly and libged is not crashing improperly.
 
 
August 19:
 
* Fixing libged commands, now they at least give some result and mostly work.
 
* Using program-wide data structures for libged, instead of on-demand ones for testing until now.
 
 
August 18:
 
* Official "Pencils down" date.
 
* I was trying to get my commands using libged working, but no luck so far and no tangible code worth to commit.
 
 
August 17:
 
* Adding a couple of new commands using libged, but still not properly working (I don't know if it's my fault or libged's)
 
 
August 15:
 
* Moving Command base class to a separate file
 
* Preparing CMake files for using BRL-CAD library
 
* Adding a new command to start to use libged (more to come, but I'm having some issues)
 
 
August 11/12:
 
* Preparing binary package so more people can test it.  Unfortunately they're only for GNU/Linux amd64, since my personal laptop got screwed and I cannot install new systems in the computer at work.  The packages are in: http://brlcad.org/~mafm/g3d-packages/ , some other libs are necessary in order to get it running: libfreeimage, libCg etc; easily available from your favourite distro or the Intertubes.
 
 
August 8:
 
* Working in the camera control window, fixing some of the remaining problems
 
* Revisiting part of the code, removing some comments not applicable anymore and doing a bit of cleanup.
 
* Starting to prepare a binary package.
 
 
August 7:
 
* Perfecting the taskbar, now it works much more closely to the Ideal Operation Environment (IOE, see my wiki page for the video) that we take as ideal interaction model
 
* Enhancing custom widget with a label and the numerical progress (useful at least when testing)
 
* Several other minor changes related with this.
 
 
August 6:
 
* After a few days of weekend and relax visiting friends and family, came back to work.
 
* Adding methods to CameraMode to retrieve the relative rotations, so (in example) they can be shown in windows
 
* Continued working with the custom widget.  It's not easy since it seems that some of the brush methods don't work (in example to draw lines), so I changed the strategy to use a kind of slider instead of a "pie" to represent the rotation.
 
 
August 1:
 
* Creating icons for camera control buttons
 
* Enhancing camera modes by adding bindings for actions in the camera control window, and binding actions in camera control window with camera modes -- some previous code needed some modifications to get this working fine.
 
  
 
== July ==
 
== July ==
  
July 31:
+
July 24:
* Working in the custom window and camera control, commiting code even if it doesn't work very well.
 
 
 
July 30:
 
* Saving the state of camera rotations before dragging, so they continue to rotate from the current position instead of starting from scratch (for both Blender and MGED modes).
 
* Working in creating a new window to control the camera, including the creation of a custom Widget (as requested by Sean, to test how easy it is to achieve that with RBGui), but results not ready to commit yet because there are lots of glitches (images not showing in buttons when they should, etc).
 
 
 
July 29:
 
* Fixing day :)
 
** Fixing the problems with zooming in orthographic mode with minimum hassle, using some of the capabilities of OGRE (instead of previous trials modifying view matrices and so on).  It works as expected with all current camera/input modes.
 
** Fixing the problems with panning when controlled by keyboard (currently for Blender Camera mode only).
 
** Fixing the problems with panning when controlled by mouse (currently for MGED/Shift-grips Camera mode only).  In the end it was very simple, but only once we got the relative dimensions of the camera and we're working in orthogonal projection mode.
 
 
 
July 28:
 
* Adding support for different projections: orthogonal(orthographic)/perspective.  Putting the control of Perspective/Orthogonal projection types in the CameraManager, so it's independent of the Camera/Input Modes (MGED, Blender, etc).
 
* When in orthogonal projection mode there's no concept of zooming, every object is projected with real size on the screen; so I started to look into how to emulate this by using view matrices and things like that.
 
 
 
July 25:
 
* Screenshot: http://brlcad.org/~mafm/g3d-screenshots/brlcad_rbgui_20080725-1.png
 
* Working on perfecting MGED (Shift-grips) mode
 
* Talking with Sean for quite a long time about mid-term evaluation, some new goals (making binary release, working in making some widget control) and stressing some things (more polishing), etc -- main things reflected in ToDo section
 
  
 
July 23:
 
July 23:

Please note that all contributions to BRL-CAD may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BRL-CAD:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)