Thread: [Plib-users] Readable user docs for PUI?
Brought to you by:
sjbaker
Menu
▾
▴
plib-users
|
From: James F. <fr...@cs...> - 2008-05-06 21:13:09
|
Hi, Does anyone know where I can find a readable/printable manual for PUI? I'd like to use it for a project I'm doing, but on my browser, the online version has chunks of a patterned green background splashed through it, making it very difficult to even read on the screen, let alone print. I don't know enough about HTML to think of an easy way to convert it to readable form. Thanks, James |
|
From: Fay J. F Dr C. U. 46 S. <joh...@eg...> - 2008-05-06 21:23:45
|
James, Hello and welcome to the PLIB community. I have found that clicking on the text, pressing "Ctrl-A" to select all of it, and then copying and pasting it into a word processor works decently. There's also a "short introduction" at ... http://plib.sourceforge.net/pui/BasicPUI.html ... which I had completely forgotten about. And if you have any questions I will probably be able to answer them. John F. Fay Technical Fellow Jacobs Technology TEAS Group 850-883-1294 -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of James Frye Sent: Tuesday, May 06, 2008 4:13 PM To: pli...@li... Subject: [Plib-users] Readable user docs for PUI? Hi, Does anyone know where I can find a readable/printable manual for PUI? I'd like to use it for a project I'm doing, but on my browser, the online version has chunks of a patterned green background splashed through it, making it very difficult to even read on the screen, let alone print. I don't know enough about HTML to think of an easy way to convert it to readable form. Thanks, James ------------------------------------------------------------------------ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j avaone _______________________________________________ plib-users mailing list pli...@li... https://lists.sourceforge.net/lists/listinfo/plib-users |
|
From: James F. <fr...@cs...> - 2008-05-07 04:52:20
|
On Tue, 6 May 2008, Fay John F Dr CTR USAF 46 SK wrote: > Hello and welcome to the PLIB community. I have found that > clicking on the text, pressing "Ctrl-A" to select all of it, and then > copying and pasting it into a word processor works decently. Duh! Why didn't I think of that? I guess because I seldom use a word processor - what little of that nature I do usually gets done in Latex. > There's also a "short introduction" at ... > > http://plib.sourceforge.net/pui/BasicPUI.html > > ... which I had completely forgotten about. And if you have any > questions I will probably be able to answer them. Thanks for the offer. What I'm trying to do is get a menu system that will work within a virtual reality library, so that instead of menus being tied to window/screen geometry, they become objects in the world. So for example if I had an ATM machine in the world, I could use the menu system to simulate the ATM buttons. Being no fonder than most of reinventing the wheel, I figured it might be simpler to modify some existing library than to start from scratch, and PUI seems much simpler (or at least the code's smaller) than the other OpenGL UIs I've found. Comments and advice are of course welcome, even (maybe especially) if they're of the "omigawd you don't know what you're getting into" sort. Thanks, James |
|
From: M&M <gon...@gm...> - 2008-05-07 10:40:46
|
Hi James, I, some how agree with you about, not only the PUI documentation, but also, all PLIB documentation... This is a PLIB maling list, so, maybe i shouldn't do this, but my real interest is to help you, so, maybe you could check other libraries, like GLUI, i've already used it, it is "supremmelly" easy to use and there is very nice documentation, google it! I hope i could help ya, Goncalo On Wed, May 7, 2008 at 5:52 AM, James Frye <fr...@cs...> wrote: > On Tue, 6 May 2008, Fay John F Dr CTR USAF 46 SK wrote: > > > Hello and welcome to the PLIB community. I have found that > > clicking on the text, pressing "Ctrl-A" to select all of it, and then > > copying and pasting it into a word processor works decently. > > Duh! Why didn't I think of that? I guess because I seldom use a word > processor - what little of that nature I do usually gets done in Latex. > > > There's also a "short introduction" at ... > > > > http://plib.sourceforge.net/pui/BasicPUI.html > > > > ... which I had completely forgotten about. And if you have any > > questions I will probably be able to answer them. > > Thanks for the offer. What I'm trying to do is get a menu system that > will work within a virtual reality library, so that instead of menus being > tied to window/screen geometry, they become objects in the world. So for > example if I had an ATM machine in the world, I could use the menu system > to simulate the ATM buttons. > > Being no fonder than most of reinventing the wheel, I figured it might be > simpler to modify some existing library than to start from scratch, and > PUI seems much simpler (or at least the code's smaller) than the other > OpenGL UIs I've found. > > Comments and advice are of course welcome, even (maybe especially) if > they're of the "omigawd you don't know what you're getting into" sort. > > Thanks, > James > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > plib-users mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-users > |
|
From: James F. <fr...@cs...> - 2008-05-07 15:19:17
|
On Wed, 7 May 2008, M&M wrote: > I, some how agree with you about, not only the PUI documentation, but also, > all PLIB documentation... > > This is a PLIB maling list, so, maybe i shouldn't do this, but my real > interest is to help you, so, maybe you could check other libraries, like > GLUI, i've already used it, it is "supremmelly" easy to use and there is > very nice documentation, google it! I've used GLUI, and agree that it is easy to use. (Haven't really used plib yet, so I can't compare the two.) However, what I'm working on now involves seriously modifying & extending whatever code I start from, and I haven't made much progress in understanding the GLUI code. I'm hoping pui will be easier to work with. Thanks, James |
|
From: Fay J. F Dr C. U. 46 S. <joh...@eg...> - 2008-05-07 17:02:32
|
Goncalo, Even though this is a PLIB mailing list, I personally have no problem with people recommending other software packages. The PLIB libraries are being offered free of charge with the LGPL license in the hope that people will find them useful; the primary focus is on enabling people to do things. John F. Fay Technical Fellow Jacobs Technology TEAS Group 850-883-1294 -----Original Message----- From: pli...@li... [mailto:pli...@li...] On Behalf Of M&M Sent: Wednesday, May 07, 2008 5:41 AM To: PLIB Users Subject: Re: [Plib-users] Readable user docs for PUI? Hi James, I, some how agree with you about, not only the PUI documentation, but also, all PLIB documentation... This is a PLIB maling list, so, maybe i shouldn't do this, but my real interest is to help you, so, maybe you could check other libraries, like GLUI, i've already used it, it is "supremmelly" easy to use and there is very nice documentation, google it! I hope i could help ya, Goncalo |
|
From: Steve B. <st...@sj...> - 2008-05-08 00:42:49
|
Fay John F Dr CTR USAF 46 SK wrote:
> Even though this is a PLIB mailing list, I personally have no problem
> with people recommending other software packages. The PLIB libraries
> are being offered free of charge with the LGPL license in the hope that
> people will find them useful; the primary focus is on enabling people to
> do things.
>
Yes - no problem. If another package is better suited than PUI to doing
the job - then by all means let us discuss that.
The problems I had with GLUI (which resulted in me writing PUI in the
first place) was that it didn't 'play nicely' with other rendering
software. It wants to "own the main loop" - PUI can be invoked as a
subroutine call at any point in the rendering cycle you like. That was
a long time ago though - it's possible that GLUI has evolved ways to
play more nicely with a primarily-non-GUI interactive application. PUI
may well be better suited on those grounds alone.
I believe you can easily attach PUI widgets to 3D surfaces - I did that
a LONG time ago though and lots has changed since then. I think you
can just get into pu.cxx and write a new function that is just like
puDisplay() but calls your own code instead of using
puSetOpenGLState(). Take out the glViewport() call, the glOrtho() and
the two glLoadIdentity() calls and push whatever transform you want onto
the stack instead. PUI disables depth-testing, fog and lighting - and
you may need to change that too. The biggest problem (IIRC) as in
transforming your mouse coordinates when you feed them to puMouse().
You can even make PUI draw a software cursor so that your control panels
have cursors that move around in perspective and such.
If you are concerned about LGPL issues, you could avoid modifying PUI
altogether by writing:
extern void puCleanUpJunk(void);
void my_puDisplay ( void )
{
...set up your opengl state...
glDisable ( GL_CULL_FACE ) ;
puCleanUpJunk () ;
puGetUltimateLiveInterface () -> draw ( 0, 0 ) ;
puDrawCursor ( myCursor_x, myCursor_y ) ;
puRefresh = FALSE ;
...restore opengl state...
}
|
|
From: James F. <fr...@cs...> - 2008-05-08 04:49:13
|
On Wed, 7 May 2008, Steve Baker wrote: > I believe you can easily attach PUI widgets to 3D surfaces - I did that > a LONG time ago though and lots has changed since then. I think you > can just get into pu.cxx and write a new function that is just like > puDisplay() but calls your own code instead of using > puSetOpenGLState(). Take out the glViewport() call, the glOrtho() and > the two glLoadIdentity() calls and push whatever transform you want onto > the stack instead. PUI disables depth-testing, fog and lighting - and > you may need to change that too. The biggest problem (IIRC) as in > transforming your mouse coordinates when you feed them to puMouse(). Hummm... I had been thinking I'd have to re-write most of the drawing code to do 3D drawing instead of 2D - e.g. calling glVertex3f instead of glVertex2i - then changing setPosition & setSize to take 3D coords, adding a setRotation, etc. This is intended to work within an existing VR library (freeVR), so the basic graphics environment gets set up there. It gives you 3D "wand" coordinates. I imagine that will involve a bit of work to find what is selected, but it seems simple in principle. > You can even make PUI draw a software cursor so that your control panels > have cursors that move around in perspective and such. Already handled by the VR lib - and of course in a CAVE-like environment it's actually tracking hand or wand position. > If you are concerned about LGPL issues... Not at all. This is just a project for a class, so odds are it won't get used afterwards. If it does, it would go into the freeVR lib that's also LGPL'd (or similar). |
|
From: Steve B. <st...@sj...> - 2008-05-08 12:09:18
|
James Frye wrote: > Hummm... I had been thinking I'd have to re-write most of the drawing > code to do 3D drawing instead of 2D - e.g. calling glVertex3f instead of > glVertex2i - then changing setPosition & setSize to take 3D coords, adding > a setRotation, etc. > Oh - no, no, no! Certainly not! PUI uses glVertex2D - but all that does is generate a full 3D vertex with Z=0,W=1. The subsequent rotate/translate/perspective transforms operate exactly the same way they do for 3D vertices. You CERTAINLY won't have to do anything like that if all you want to do is to simulate a 2D GUI on a virtual 2D display placed somewhere out in the 3D world. Once you have the right transform on the stack, PUI will render in full 3D just fine. One thing you MIGHT have problems with is that PUI doesn't clip it's underlying primitives to the screen - it lets OpenGL do that. You'll need to set up some user clip planes to fix that properly - but you could consider cheating and building your virtual monitor with a nice chunky frame that Z-buffers out the PUI widgets that hang off the edges of the screen a bit. Actually - the super-modern way to do this would be to leave PUI 100% alone and simply have it render to an RGB texture instead of to the screen. Set up a render-to-texture rendering target - run PUI exactly as you would normally - then apply that texture to your virtual computer screen. That would completely take care of the clipping problem and allow you to use PUI's standard puDisplay() function. Then you can apply that texture to any polygon(s) in your 3D scene and be utterly assured that everything will play nicely. If you have multiple PUI screens in your virtual world then you could also gain some performance by only re-rendering the texture for the screen that the user is interacting with. That would be really cool actually - you could easily have PUI displayed on translucent screens (like on the movie "Minority Report") or whatever. If you are familiar with the render-to-texture approach then you should be able to get this working with just a couple of hour's work and no changes whatever to the PUI source. This would be by far the simplest way to do it. > This is intended to work within an existing VR library (freeVR), so the > basic graphics environment gets set up there. It gives you 3D "wand" > coordinates. I imagine that will involve a bit of work to find what is > selected, but it seems simple in principle. > That should make finding the "mouse" coordinates a lot simpler. >> You can even make PUI draw a software cursor so that your control panels >> have cursors that move around in perspective and such. >> > Already handled by the VR lib - and of course in a CAVE-like environment > it's actually tracking hand or wand position. > OK...But I think I'd leave PUI's software cursor alone because seeing that start to track when your virtual hand touches the PUI screen would give the end user the confidence that they are indeed driving this virtual touch-screen. But that's obviously something you are better placed to figure out than me! -- Steve. |
|
From: James F. <fr...@cs...> - 2008-05-08 22:40:24
|
On Thu, 8 May 2008, Steve Baker wrote: > James Frye wrote: >> Hummm... I had been thinking I'd have to re-write most of the drawing >> code to do 3D drawing instead of 2D - e.g. calling glVertex3f instead of >> glVertex2i - then changing setPosition & setSize to take 3D coords, adding >> a setRotation, etc. >> > Oh - no, no, no! Certainly not! PUI uses glVertex2D - but all that > does is generate a full 3D vertex with Z=0,W=1. The subsequent > rotate/translate/perspective transforms operate exactly the same way > they do for 3D vertices. You CERTAINLY won't have to do anything like > that if all you want to do is to simulate a 2D GUI on a virtual 2D > display placed somewhere out in the 3D world. Well, I do want more than that: the ability to use the functions in any way needed. It might be a display on a simulated device somewhere in the world, or it might be simulated buttons on a device the user carries with him, or "magic" system menus that the user can pull out of thin air, as it were. So it seems that somehow pui has to be altered/extended so that each menu carries around its 3D transform information, then puDisplay (or code beneath) contains a loop that sets the transform for each menu. And of course the transform can be dynamically modified, if for instance the menu is attached to a moving object... > Once you have the right transform on the stack, PUI will render in full > 3D just fine. > > One thing you MIGHT have problems with is that PUI doesn't clip it's > underlying primitives to the screen - it lets OpenGL do that. You'll > need to set up some user clip planes to fix that properly - but you > could consider cheating and building your virtual monitor with a nice > chunky frame that Z-buffers out the PUI widgets that hang off the edges > of the screen a bit. May not be a problem, since in a CAVE environment there aren't any edges... > Actually - the super-modern way to do this would be to leave PUI 100% > alone and simply have it render to an RGB texture instead of to the > screen. Set up a render-to-texture rendering target - run PUI exactly > as you would normally - then apply that texture to your virtual computer > screen. That would completely take care of the clipping problem and > allow you to use PUI's standard puDisplay() function. Then you can > apply that texture to any polygon(s) in your 3D scene and be utterly > assured that everything will play nicely. If you have multiple PUI > screens in your virtual world then you could also gain some performance > by only re-rendering the texture for the screen that the user is > interacting with. That would be really cool actually - you could easily > have PUI displayed on translucent screens (like on the movie "Minority > Report") or whatever. > > If you are familiar with the render-to-texture approach then you should > be able to get this working with just a couple of hour's work and no > changes whatever to the PUI source. This would be by far the simplest > way to do it. I'm not really familiar with textures at all. What I've done with OpenGL has always been things like data display, where you draw objects/surfaces, and color them according to data values. |
|
From: James F. <fr...@cs...> - 2008-05-11 16:44:37
|
Hi, I'm making some progress on modifying PUI to work with VR, but have a couple more questions. After a few modifications (such as replacing the bitmapped text with GLUT vector fonts), I've got groups containing buttons and such that I can move around & rotate at will. Now I want to add a nice frame around a group, but it seems that I have to create the frame before creating the objects that go in it. IOW the code needs to look something like group = new puGroup (size...) frame = new puFrame (x1, y1, x2, y2); button1 = new puButton (x, y, label); button2 = new puButton (x, y, label); group->close (); The problem is how to know the dimensions for frame before I create at least one button, and find its size? That leads to a larger question: what does PUI use as its internal coordinate system? At some point I'll need to add scaling of the PUI coordinate system to the VR one, so that the menus appear at virtual world sizes. I'd rather not do this by trial & error, but I don't understand the internal coordinates from the code. Thanks, James |
|
From: Steve B. <st...@sj...> - 2008-05-07 02:35:59
|
I don't know what browser you are using - but Firefox has no problem in printing the online PUI manual. When you print it, the background is automatically removed and the text is printed black. I don't see any patterned green in the printed version - although there are some diagrams. As far as I know, all browsers do that by default. Anyway, the online PUI manual is the only documentation in existence. James Frye wrote: > Hi, > > Does anyone know where I can find a readable/printable manual for PUI? > I'd like to use it for a project I'm doing, but on my browser, the online > version has chunks of a patterned green background splashed through it, > making it very difficult to even read on the screen, let alone print. I > don't know enough about HTML to think of an easy way to convert it to > readable form. > > Thanks, > James > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > plib-users mailing list > pli...@li... > https://lists.sourceforge.net/lists/listinfo/plib-users > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X