From info-volumizer-owner@els.sgi.com Mon Nov 7 02:34:21 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jA7AWoNA8828424; Mon, 7 Nov 2005 02:32:50 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jA7AUHJT8845166; Mon, 7 Nov 2005 02:30:18 -0800 (PST) Received: from mtv-atc-013e--n.corp.sgi.com (mtv-atc-013e--n.corp.sgi.com [192.26.78.50]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA7AXfAQ69210864; Mon, 7 Nov 2005 02:33:41 -0800 (PST) Received: from praveenlaptop (134.14.90.125 [134.14.90.125]) by mtv-atc-013e--n.corp.sgi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WL5VAV84; Mon, 7 Nov 2005 02:30:17 -0800 From: "Praveen Bhaniramka" To: , , Subject: [info-volumizer] OpenGL Multipipe SDK 3.2 available for download!!! Date: Mon, 7 Nov 2005 16:00:10 +0530 Message-ID: <019001c5e386$3f35cb20$2d000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi all, OpenGL Multipipe SDK 3.2 is now available for download from the product download pages. The 3.2 version adds following new features - - Support for 32-bit Linux platforms o SUSE LINUX 9.1 or later o Redhat Enterprise Linux (RHEL) 3 or later - Performance Enhancement features for Silicon Graphics Prism Systems o Auto runon support for better CPU placement of rendering threads o Improved color image readback performance - New Build Environment for installed sample code - New Sample applications with installed sample code o Sample viewer applications - flip.pdb and flip.ply Instructions for downloading the rpms - 1. Go to http://support.sgi.com 2. Use your Supportfolio account (you would need to create a new one, if you don't have an account already) to login 3. Select "Download Cool Software" from the "Download" section. 4. Select the product that you want to download. Kindly note the following about this release: - The 32-bit Linux version uses run-time licensing based upon a FlexLM license key. The full-featured demo edition is still available for free (adds a "OpenGL Multipipe SDK" banner to the application windows). - New versions of the product will not be available on IRIX. IRIX users are recommended to use the 3.1.1 release, which is also available from the Supportfolio pages. Please let us know if you have any questions about the product. Enjoy, Praveen From info-volumizer-owner@els.sgi.com Wed Nov 9 04:53:50 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jA9CqIJs8891098; Wed, 9 Nov 2005 04:52:18 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jA9Cp6JT8912542 for ; Wed, 9 Nov 2005 04:51:06 -0800 (PST) Received: from mtv-atc-013e--n.corp.sgi.com (mtv-atc-013e--n.corp.sgi.com [192.26.78.50]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA9CsWAQ69906912 for ; Wed, 9 Nov 2005 04:54:33 -0800 (PST) Received: from praveenlaptop (134.14.90.125 [134.14.90.125]) by mtv-atc-013e--n.corp.sgi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WL5VAX7V; Wed, 9 Nov 2005 04:51:05 -0800 From: "Praveen Bhaniramka" To: Subject: [info-volumizer] Re: [info-performer] OpenGL Multipipe SDK 3.2 available for download!!! Date: Wed, 9 Nov 2005 18:20:54 +0530 Message-ID: <02e501c5e52c$3c9ef7e0$2d000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com [forwarding to info-volumizer. The message was deleted from the queue accidentally by me] Hi, downloaded and installed successfully, but where can I get a valid license.dat for mpk ? regards, Mathieu Praveen Bhaniramka wrote: > Hi all, > > OpenGL Multipipe SDK 3.2 is now available for download from the product > download pages. > > The 3.2 version adds following new features - > - Support for 32-bit Linux platforms > o SUSE LINUX 9.1 or later > o Redhat Enterprise Linux (RHEL) 3 or later > - Performance Enhancement features for Silicon Graphics Prism Systems > o Auto runon support for better CPU placement of rendering threads > o Improved color image readback performance > - New Build Environment for installed sample code > - New Sample applications with installed sample code > o Sample viewer applications - flip.pdb and flip.ply > > Instructions for downloading the rpms - > 1. Go to http://support.sgi.com > 2. Use your Supportfolio account (you would need to create a new one, if > you don't have an account already) to login > 3. Select "Download Cool Software" from the "Download" section. > 4. Select the product that you want to download. > > Kindly note the following about this release: > - The 32-bit Linux version uses run-time licensing based upon a FlexLM > license key. The full-featured demo edition is still available for free > (adds a "OpenGL Multipipe SDK" banner to the application windows). > - New versions of the product will not be available on IRIX. IRIX users > are recommended to use the 3.1.1 release, which is also available from > the Supportfolio pages. > > Please let us know if you have any questions about the product. > > Enjoy, > Praveen > > ----------------------------------------------------------------------- > List Archives, Info, FAQ: http://www.sgi.com/software/performer/ > Open Development Project: http://oss.sgi.com/projects/performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > ----------------------------------------------------------------------- From info-volumizer-owner@els.sgi.com Wed Nov 9 13:08:14 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jA9L7MFu8924681; Wed, 9 Nov 2005 13:07:22 -0800 (PST) Received: from surfboard.ka.sara.nl (surfboard.ka.sara.nl [145.100.6.3]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jA9ERUJT8930812 for ; Wed, 9 Nov 2005 06:27:30 -0800 (PST) Received: from [145.100.25.205] ([145.100.25.205] RDNS failed) by surfboard.ka.sara.nl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Nov 2005 15:27:25 +0100 Message-ID: <4372074D.8030302@sara.nl> Date: Wed, 09 Nov 2005 15:27:25 +0100 From: Jeroen Akershoek Organization: SARA User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: info-volumizer@els.sgi.com Subject: [info-volumizer] 64 bit Volumizer on IRIX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2005 14:27:25.0149 (UTC) FILETIME=[B45800D0:01C5E539] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hello, We've got some Volumizer code on IRIX that we wanted to build as 64-bit, but we found that it gives a bus error Reducing the code size gave us the following piece of code that fails: #include int main (int argc, char **argv) { vzTMRenderAction *renderaction = new vzTMRenderAction(1); return 0; } Should work, right? :) Buildline is CC test.cpp -64 -o test -l vz When build without the -64 (so in normal N32 mode) it works fine Platform is IRIX 6.5.27, Volumizer 2.8 Kind regards, Jeroen -- Jeroen Akershoek SARA Computing and Network Services - Visualisation department tel: +31 20 5923000 fax: +31 20 6683167 Draco dormiens nunquam titillandus From info-volumizer-owner@els.sgi.com Wed Nov 9 13:08:14 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jA9L7rbu8758879; Wed, 9 Nov 2005 13:07:53 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jA9D4sJT8945318; Wed, 9 Nov 2005 05:04:56 -0800 (PST) Received: from mtv-atc-013e--n.corp.sgi.com (mtv-atc-013e--n.corp.sgi.com [192.26.78.50]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA9D8LAQ69876127; Wed, 9 Nov 2005 05:08:21 -0800 (PST) Received: from praveenlaptop (134.14.90.125 [134.14.90.125]) by mtv-atc-013e--n.corp.sgi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WL5VAX7X; Wed, 9 Nov 2005 05:04:53 -0800 From: "Praveen Bhaniramka" To: "'MARACHE Mathieu'" Cc: , , , "'Tiffany To'" Subject: [info-volumizer] RE: [info-performer] OpenGL Multipipe SDK 3.2 available for download!!! Date: Wed, 9 Nov 2005 18:34:40 +0530 Message-ID: <02f401c5e52e$2a22b0a0$2d000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4371ECA5.7060507@cstb.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Marache, Tiffany To is the product manager for Multipipe SDK. She can help you out with this issue. - Praveen > -----Original Message----- > From: owner-info-performer@performer.engr.sgi.com > [mailto:owner-info-performer@performer.engr.sgi.com] On > Behalf Of MARACHE Mathieu > Sent: Wednesday, November 09, 2005 6:04 PM > To: Praveen Bhaniramka > Cc: info-volumizer@els.sgi.com; mpsdk@els.sgi.com; > info-performer@sgi.com > Subject: Re: [info-performer] OpenGL Multipipe SDK 3.2 > available for download!!! > > > Hi, > > downloaded and installed successfully, but where can I get a valid > license.dat for mpk ? > > regards, > Mathieu > > Praveen Bhaniramka wrote: > > Hi all, > > > > OpenGL Multipipe SDK 3.2 is now available for download from > the product > > download pages. > > > > The 3.2 version adds following new features - > > - Support for 32-bit Linux platforms > > o SUSE LINUX 9.1 or later > > o Redhat Enterprise Linux (RHEL) 3 or later > > - Performance Enhancement features for Silicon Graphics > Prism Systems > > o Auto runon support for better CPU placement of > rendering threads > > o Improved color image readback performance > > - New Build Environment for installed sample code > > - New Sample applications with installed sample code > > o Sample viewer applications - flip.pdb and flip.ply > > > > Instructions for downloading the rpms - > > 1. Go to http://support.sgi.com > > 2. Use your Supportfolio account (you would need to create > a new one, if > > you don't have an account already) to login > > 3. Select "Download Cool Software" from the "Download" section. > > 4. Select the product that you want to download. > > > > Kindly note the following about this release: > > - The 32-bit Linux version uses run-time licensing based > upon a FlexLM > > license key. The full-featured demo edition is still > available for free > > (adds a "OpenGL Multipipe SDK" banner to the application windows). > > - New versions of the product will not be available on > IRIX. IRIX users > > are recommended to use the 3.1.1 release, which is also > available from > > the Supportfolio pages. > > > > Please let us know if you have any questions about the product. > > > > Enjoy, > > Praveen > > > > > -------------------------------------------------------------- > --------- > > List Archives, Info, FAQ: http://www.sgi.com/software/performer/ > > Open Development Project: http://oss.sgi.com/projects/performer/ > > Submissions: info-performer@sgi.com > > Admin. requests: info-performer-request@sgi.com > > > -------------------------------------------------------------- > --------- > > -------------------------------------------------------------- > --------- > List Archives, Info, FAQ: http://www.sgi.com/software/performer/ > Open Development Project: http://oss.sgi.com/projects/performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > -------------------------------------------------------------- > --------- > From info-volumizer-owner@els.sgi.com Wed Nov 9 13:08:14 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jA9L7M3I8473922; Wed, 9 Nov 2005 13:07:22 -0800 (PST) Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jA9IRIJT8949996; Wed, 9 Nov 2005 10:27:18 -0800 (PST) Received: from mtv-amer002e--3.americas.sgi.com ([192.26.64.114]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA9IRH2Z284484300; Wed, 9 Nov 2005 10:27:17 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [info-volumizer] RE: [info-performer] OpenGL Multipipe SDK 3.2 available for download!!! Date: Wed, 9 Nov 2005 10:27:17 -0800 Message-ID: <59F6EC903C7A9E48974AEFE62959736F1C9D05@mtv-amer002e--3.americas.sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [info-performer] OpenGL Multipipe SDK 3.2 available for download!!! Thread-Index: AcXlLi2/XmbqFU7sSz2eP+mEtO4MzgAKNU4A From: "Tiffany To" To: "Praveen Bhaniramka" , "MARACHE Mathieu" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by els.sgi.com id jA9IRIJU8916726 Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Mathieu, Thanks for your interest in the 32-bit version of MPK. Since this is the first release of the 32-bit version, the product team is greatly interested in understanding how it will be utilized by users such as yourself. If you could send me a paragraph or so about your organization, the application(s) you're developing and your goals with the MPK product, I would be happy to generate a complimentary license for you. Please include your system info, specifically, the MAC address for eth0 (primary NIC interface) for license generation purposes. We look forward to your feedback, - t t ________________________ T i f f a n y T o Product Manager Visual Systems Group, SGI 1500 Crittenden Lane ms. 526 Mountain View, CA 94043 Phone: 650.933.2327 Email: tiffany@sgi.com -----Original Message----- From: Praveen Bhaniramka [mailto:praveenb@sgi.com] Sent: Wednesday, November 09, 2005 5:05 AM To: 'MARACHE Mathieu' Cc: info-volumizer@els.sgi.com; mpsdk@els.sgi.com; info-performer@sgi.com; Tiffany To Subject: RE: [info-performer] OpenGL Multipipe SDK 3.2 available for download!!! Hi Marache, Tiffany To is the product manager for Multipipe SDK. She can help you out with this issue. - Praveen > -----Original Message----- > From: owner-info-performer@performer.engr.sgi.com > [mailto:owner-info-performer@performer.engr.sgi.com] On > Behalf Of MARACHE Mathieu > Sent: Wednesday, November 09, 2005 6:04 PM > To: Praveen Bhaniramka > Cc: info-volumizer@els.sgi.com; mpsdk@els.sgi.com; > info-performer@sgi.com > Subject: Re: [info-performer] OpenGL Multipipe SDK 3.2 > available for download!!! > > > Hi, > > downloaded and installed successfully, but where can I get a valid > license.dat for mpk ? > > regards, > Mathieu > > Praveen Bhaniramka wrote: > > Hi all, > > > > OpenGL Multipipe SDK 3.2 is now available for download from > the product > > download pages. > > > > The 3.2 version adds following new features - > > - Support for 32-bit Linux platforms > > o SUSE LINUX 9.1 or later > > o Redhat Enterprise Linux (RHEL) 3 or later > > - Performance Enhancement features for Silicon Graphics > Prism Systems > > o Auto runon support for better CPU placement of > rendering threads > > o Improved color image readback performance > > - New Build Environment for installed sample code > > - New Sample applications with installed sample code > > o Sample viewer applications - flip.pdb and flip.ply > > > > Instructions for downloading the rpms - > > 1. Go to http://support.sgi.com > > 2. Use your Supportfolio account (you would need to create > a new one, if > > you don't have an account already) to login > > 3. Select "Download Cool Software" from the "Download" section. > > 4. Select the product that you want to download. > > > > Kindly note the following about this release: > > - The 32-bit Linux version uses run-time licensing based > upon a FlexLM > > license key. The full-featured demo edition is still > available for free > > (adds a "OpenGL Multipipe SDK" banner to the application windows). > > - New versions of the product will not be available on > IRIX. IRIX users > > are recommended to use the 3.1.1 release, which is also > available from > > the Supportfolio pages. > > > > Please let us know if you have any questions about the product. > > > > Enjoy, > > Praveen > > > > > -------------------------------------------------------------- > --------- > > List Archives, Info, FAQ: http://www.sgi.com/software/performer/ > > Open Development Project: http://oss.sgi.com/projects/performer/ > > Submissions: info-performer@sgi.com > > Admin. requests: info-performer-request@sgi.com > > > -------------------------------------------------------------- > --------- > > -------------------------------------------------------------- > --------- > List Archives, Info, FAQ: http://www.sgi.com/software/performer/ > Open Development Project: http://oss.sgi.com/projects/performer/ > Submissions: info-performer@sgi.com > Admin. requests: info-performer-request@sgi.com > -------------------------------------------------------------- > --------- > From info-volumizer-owner@els.sgi.com Wed Nov 9 13:17:44 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jA9LHRqY8382865; Wed, 9 Nov 2005 13:17:27 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jA9LGXJT8808283 for ; Wed, 9 Nov 2005 13:16:33 -0800 (PST) Received: from mtv-atc-013e--n.corp.sgi.com (mtv-atc-013e--n.corp.sgi.com [192.26.78.50]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA9LJxAQ70018469 for ; Wed, 9 Nov 2005 13:19:59 -0800 (PST) Received: from praveenlaptop (134.14.90.125 [134.14.90.125]) by mtv-atc-013e--n.corp.sgi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WL5VAYAJ; Wed, 9 Nov 2005 13:16:32 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] 64 bit Volumizer on IRIX Date: Thu, 10 Nov 2005 02:46:19 +0530 Message-ID: <035901c5e572$d82987c0$2d000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4372074D.8030302@sara.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Jeroen, Typically, your application should have a valid OpenGL context before you create or use a render action. In the constructor for the render action, Volumizer does create a dummy GL context for querying certain parameters in case the OpenGL context is NULL, but I would not rely on that. I am sure that this works on the current versions of the software - not sure about the older IRIX versions. Try setting the env variable VOLUMIZER_DEBUG_LEVEL to 5 and see if the output on the console helps you locate the problem. - Praveen > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Jeroen > Akershoek > Sent: Wednesday, November 09, 2005 7:57 PM > To: info-volumizer@els.sgi.com > Subject: [info-volumizer] 64 bit Volumizer on IRIX > > > Hello, > > We've got some Volumizer code on IRIX that we wanted to build > as 64-bit, > but we found that it gives a bus error > Reducing the code size gave us the following piece of code that fails: > > #include > int main (int argc, char **argv) > { > vzTMRenderAction *renderaction = new vzTMRenderAction(1); > return 0; > } > > Should work, right? :) > > Buildline is CC test.cpp -64 -o test -l vz > When build without the -64 (so in normal N32 mode) it works fine > > Platform is IRIX 6.5.27, Volumizer 2.8 > > Kind regards, > Jeroen > > -- > Jeroen Akershoek > SARA Computing and Network Services - Visualisation department > tel: +31 20 5923000 fax: +31 20 6683167 > > Draco dormiens nunquam titillandus > From info-volumizer-owner@els.sgi.com Thu Nov 10 01:54:50 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jAA9rYD58856402; Thu, 10 Nov 2005 01:53:34 -0800 (PST) Received: from surfboard.ka.sara.nl (surfboard.ka.sara.nl [145.100.6.3]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jAA82cJT8916454 for ; Thu, 10 Nov 2005 00:02:39 -0800 (PST) Received: from [145.100.25.205] ([145.100.25.205] RDNS failed) by surfboard.ka.sara.nl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Nov 2005 09:02:33 +0100 Message-ID: <4372FE9B.5050002@sara.nl> Date: Thu, 10 Nov 2005 09:02:35 +0100 From: Jeroen Akershoek Organization: SARA User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] 64 bit Volumizer on IRIX References: <035901c5e572$d82987c0$2d000f86@asiapac.sgi.com> In-Reply-To: <035901c5e572$d82987c0$2d000f86@asiapac.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2005 08:02:33.0853 (UTC) FILETIME=[1B459AD0:01C5E5CD] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Praveen Bhaniramka wrote: >Jeroen, > >Typically, your application should have a valid OpenGL context before >you create or use a render action. In the constructor for the render >action, Volumizer does create a dummy GL context for querying certain >parameters in case the OpenGL context is NULL, but I would not rely on >that. I am sure that this works on the current versions of the software >- not sure about the older IRIX versions. > >Try setting the env variable VOLUMIZER_DEBUG_LEVEL to 5 and see if the >output on the console helps you locate the problem. > > Volumizer (2): NULL GLXContext. Creating dummy context!!! So yes, it does seem to be a missing GL context. However, that still leaves the situation where the application runs fine in 32 bits mode. When disabling the Volumizer rendering the rest of the application runs fine in 64 bits mode as well. Kind regards, Jeroen -- Jeroen Akershoek SARA Computing and Network Services - Visualisation department tel: +31 20 5923000 fax: +31 20 6683167 Draco dormiens nunquam titillandus From info-volumizer-owner@els.sgi.com Thu Nov 10 02:14:48 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jAAAEFa38934394; Thu, 10 Nov 2005 02:14:15 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jAAA9sJT8918607 for ; Thu, 10 Nov 2005 02:09:55 -0800 (PST) Received: from mtv-atc-013e--n.corp.sgi.com (mtv-atc-013e--n.corp.sgi.com [192.26.78.50]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAAADLAQ70196867 for ; Thu, 10 Nov 2005 02:13:21 -0800 (PST) Received: from praveenlaptop (134.14.90.125 [134.14.90.125]) by mtv-atc-013e--n.corp.sgi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WL5VAYT5; Thu, 10 Nov 2005 02:09:55 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] 64 bit Volumizer on IRIX Date: Thu, 10 Nov 2005 15:39:40 +0530 Message-ID: <042b01c5e5de$e1567fd0$2d000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4372FE9B.5050002@sara.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hi Jeroen, I agree that this could as well be a Volumizer issue with the 64-bit version of the library, but with the given information, it is hard for me to propose any solution for the issue. Couple of things that you can try to localize the issue - 1. Try linking with the debug version of the library under /usr/lib64/debug by setting the LD_LIBRARY_PATH env variable and run the app under dbx to see the stack. 2. Use the debug messages to see if Volumizer actually throws a vzError::error or it is some other issue somewhere. Thanks, Praveen > Volumizer (2): NULL GLXContext. Creating dummy context!!! > > So yes, it does seem to be a missing GL context. However, that still > leaves the > situation where the application runs fine in 32 bits mode. When > disabling the > Volumizer rendering the rest of the application runs fine in > 64 bits mode as > well. > > Kind regards, > Jeroen > > -- > Jeroen Akershoek > SARA Computing and Network Services - Visualisation department > tel: +31 20 5923000 fax: +31 20 6683167 > > Draco dormiens nunquam titillandus > From info-volumizer-owner@els.sgi.com Thu Nov 10 07:52:50 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jAAFpQ8c8473904; Thu, 10 Nov 2005 07:51:26 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jAAFQBJT8941709 for ; Thu, 10 Nov 2005 07:26:12 -0800 (PST) Received: by wproxy.gmail.com with SMTP id i20so373417wra for ; Thu, 10 Nov 2005 07:26:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Yqpe+Olt0KU54DmXdIkDMomwaSG3p0r65CkgdEOlscNFX/CABHarPXg5vgXkIY8KwKRzu05rOiiFSCU929p/HN63jWDZyxa4lVvIHIaHIfkiaKKqOtFGBgFuxvdyRUMEcD8g3YdFJOL1nUjfbcg6S+BIueV0hPteSPT0hpKeUKA= Received: by 10.64.91.5 with SMTP id o5mr279590qbb; Thu, 10 Nov 2005 07:26:06 -0800 (PST) Received: by 10.65.155.20 with HTTP; Thu, 10 Nov 2005 07:26:05 -0800 (PST) Message-ID: Date: Thu, 10 Nov 2005 10:26:06 -0500 From: Kevin Wang To: praveenb@sgi.com, info-volumizer@els.sgi.com Subject: [info-volumizer] Re: Cg support in OpenGL multipipe In-Reply-To: <046801c5e5e1$b6c31e10$2d000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_34793_4812203.1131636366005" References: <046801c5e5e1$b6c31e10$2d000f86@asiapac.sgi.com> Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com ------=_Part_34793_4812203.1131636366005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I did not get any compilation errors. I set $VOLUMIZER_DEBUG_LEVEL to 5 to see all the debug info and I can see nothing wrong. Well, maybe early ray termination is not a good idea for 3D texture mapping= . Do you guys have a plan to implement GPU based ray casting in Volumizer? -- Kevin On 11/10/05, Praveen Bhaniramka wrote: > > Not sure what is going on. Do you get any errors from Volumizer about the > shader compilation? If the shader does not compile, Volumizer will give y= ou > an error. > Volumizer will always use back-to-front slicing based on the transform > matrices set by the application. So, mucking with the matrices might not > really help. I will try and think about some other solution for you as we= ll. > > - Praveen > > -----Original Message----- > *From:* Kevin Wang [mailto:kwang22@gmail.com] > *Sent:* Thursday, November 10, 2005 1:17 AM > *To:* praveenb@sgi.com > *Subject:* Re: Cg support in OpenGL multipipe > > Hi Praveen, > > Thanks for your ideas. > > I have tried your second recommendation regarding interpolation mode usin= g > the following GLSL program. > > "vec3 coordinates, delta, integal;\n" > "coordinates.s =3D volume_TexCoord.s * volume_TexDims.x;\n" > "coordinates.t =3D volume_TexCoord.t * volume_TexDims.y;\n" > "coordinates.p =3D volume_TexCoord.p * volume_TexDims.z;\n" > "delta.s =3D floor(coordinates.s);\n" > "delta.t =3D floor(coordinates.t);\n" > "delta.p =3D floor(coordinates.p);\n" > "integal.s =3D (delta.s ) / volume_TexDims.x;\n" > "integal.t =3D (delta.t ) / volume_TexDims.y;\n" > "integal.p =3D (delta.p ) / volume_TexDims.z;\n" > "color =3D texture3D(volume,integal.stp);\n" > > Originally the code is > "color =3D texture3D(volume,volume_TexCoord.stp);\n" > > Now the problem is that nothing shows up in my program. Since I am new to > GLSL so I wonder if you can test this code for me. Thanks in advance. > > As regard to empty space leaping, I think your idea is good but usually > out data (maily medical imaging data) have very few empty spaces so I wou= ld > not pursue in that direction. Early ray termination uses different render= ing > order and that is really a problem. Do you think if it is possible to ren= der > the volume in the opposite direction so that the rendering order will be > changed to front to back in volumizer? this needs to change modelviewproj= ect > matrix and manipulate the depth test. I have not thought carefully about > this. and it can be too complicated in practice. > > -- Kevin > > > > On 11/8/05, Praveen Bhaniramka wrote: > > > > Kevin, > > I am not sure if you can change the interpolation filter in > > TMFragmentShader or not. You should try using the callbacks and see if = they > > do the right thing for you. Another option would be to compute the > > "integral" texture coordinates in the fragment shader and then use them= to > > sample the textures that you want to be NEAREST filtered. You can do > > somehting like - > > vec3 coordinates =3D volume_TexCoord * volume_TexDims; > > vec3 delta =3D fract(coordinates); > > vec3 integal =3D (coordinates - delta) / volume_TexDims; > > Yeah... I am sure that there are ways to improve the texture rendering > > using early ray termination and empty space leaping with Volumizer. You= are > > right that 3D texture rendering is brute force in the sense that it sli= ces > > the complete volume and renders the data. One easy way to implement emp= ty > > space leaping is to compute a bounding geometry of the volume data that= you > > know is visible and "cut-out", using geometry, the data that is not vis= ible. > > Then use this bounding geometry for rendering the volume data set. That > > should improve the performance a bit. I am sure that early ray terminat= ion > > etc is also possible,.. I just haven't thought about that a lot. One > > potential issue there is that Volumizer currently does back-to-front > > rendering and early ray termination is typically useful for front-to-ba= ck > > rendering. Front-to-back rendering has other issues with embedded polyg= onal > > geometry in the same scene, etc. > > Let me know if you have other ideas or questions. > > - Praveen > > > > -----Original Message----- > > *From:* Kevin Wang [mailto:kwang22@gmail.com] > > *Sent:* Wednesday, November 09, 2005 3:11 AM > > *To:* praveenb@sgi.com > > *Subject:* Re: Cg support in OpenGL multipipe > > > > Hi Praveen, > > > > Thanks for your reply. I am using vzTMFragmentShader class, is it > > possible to change interpolation mode for it? > > > > Also I am thinking about ways to improve either quality or speed of > > volumizer. do you think it is possible to implement technique like earl= y ray > > termination for volumizer so that only a fraction of the slices need to= be > > rendered ( when the opacity reaches 1 then set Z buffer and using depth= test > > to by pass rendering) ? As I understand, 3D texture mapping slices the > > volume and renders all the slices. > > > > Regards, > > > > -- Kevin > > > > On 11/5/05, Praveen Bhaniramka wrote: > > > > > > Hi Kevin, > > > Currently, it is not possible to change the interpolation mode in > > > Volumizer for the built-in shaders (LUT, Gradient, Tag, etc). The > > > interpolation mode is set to be GL_LINEAR for all vzParameterVolumeTe= xture's > > > and GL_NEAREST for all vzParameterLookupTable's used in the shader. > > > However, if you are using vzTMFragmentProgram shader, Volumizer > > > provides you callbacks for binding your various textures. In those > > > callbacks, after you bind the volume texture (by using the > > > bindVolumeTextureCB function), you set the interpolation modes using = the > > > glTexParameteri() commands. > > > - Praveen > > > > > > -----Original Message----- > > > *From:* Kevin Wang [mailto: kwang22@gmail.com] > > > *Sent:* Saturday, November 05, 2005 1:51 AM > > > *To:* praveenb@sgi.com > > > *Subject:* Re: Cg support in OpenGL multipipe > > > > > > Praveen, > > > > > > Sorry I did not mean to use Cg compiler. I mean similarly it would > > > apply to a GLSL compiler. anyway, it is not urgent now. > > > > > > I have got a new question for you now. I know volumizer uses 3D > > > texture mapping technique. and when using it, usually we need to spec= ify the > > > interpolation mode during the texture setup. I wonder if there is a w= ay i > > > can change this mode during rendering with Volumizer? below is the Op= enGL > > > code to set up the interpolation mode. I want to use nearest neighbor= mode > > > in certain situations. > > > > > > glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MIN_FILTER, GL_LINEAR); > > > glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MAX_FILTER, GL_LINEAR); > > > > > > Look forward to your response. Thanks. > > > > > > -- Kevin > > > > > > On 11/4/05, Praveen Bhaniramka wrote: > > > > > > > > I am not sure if Cg compiler provides the option of converting GLSL > > > > to ARB_fragment_program. > > > > - Praveen > > > > > > > > -----Original Message----- > > > > *From:* Kevin Wang [mailto: kwang22@gmail.com] > > > > *Sent:* Friday, November 04, 2005 8:41 PM > > > > *To:* praveenb@sgi.com > > > > *Subject:* Re: Cg support in OpenGL multipipe > > > > > > > > Hi Praveen, > > > > > > > > Thanks for your response. Yes, I am using Propack 3 and we dont > > > > anticipate a system upgrade within the next half year. since the co= de is > > > > still in development stage, i guess we can wait for a while for the= upgrade. > > > > > > > > > > > > Interesting that Cg program can be convert into a > > > > ARB_Fragment_program. then I would assume that so does GLSL program= . I will > > > > look into that matter. > > > > > > > > Regards, > > > > > > > > -- Kevin > > > > > > > > On 11/4/05, Praveen Bhaniramka wrote: > > > > > > > > > > Hi Kevin, > > > > > I am pretty sure that OpenGL Multipipe does not support Cg. The > > > > > simple reason is that Prism does not support Cg and OpenGL Multip= ipe can > > > > > only run on Prism! Actually, I got the following response from Gu= y, who is > > > > > the tech lead on OMP. > > > > > "OMP will support GLSL only with Propack 4 SP3. About performanc= e > > > > > improvement with OMP, if the app is fill limited (as I assume it > > > > > should be) then OMP should scale the perfirmance." > > > > > I would imagine that your Prism is currently running ProPack 3.x= . > > > > > So in order to use GLSL, you would need to use PP4 SP3 (which wil= l be > > > > > available in December AFAIK). For now, your best bet is to use > > > > > ARB_fragment_program in Volumizer. You can still use Cg by runnin= g the Cg > > > > > compiler and passing it your Cg program and asking it to convert = the Cg > > > > > program to ARB_fragment_program. You can then pass the fragment p= rogram to > > > > > Volumizer directly. > > > > > (Sorry for the delay in replying... I was travelling last week > > > > > and earlier this week) > > > > > hth, > > > > > Praveen > > > > > > > > > > -----Original Message----- > > > > > *From:* Kevin Wang [mailto:kwang22@gmail.com] > > > > > *Sent:* Monday, October 24, 2005 9:57 PM > > > > > *To:* Saurabh Gupta; Praveen Bhaniramka > > > > > *Subject:* Cg support in OpenGL multipipe > > > > > *Importance:* Low > > > > > > > > > > Hi Saurabh and Praveen, > > > > > > > > > > Do you guys know that if OpenGL multipipe supports Cg shading > > > > > language? We have a custom developed raycasting volume rendering = software > > > > > package which uses opengl shading language. Praveen said that OMP= doesnot > > > > > support OpenGL shading language so I was wondering if it supports= Cg or > > > > > other high level shading language. and if possible, will the next= release > > > > > support OpenGL shading language? > > > > > > > > > > Regards, > > > > > > > > > > -- Kevin > > > > > > > > > > > > > > > > > > > > ------=_Part_34793_4812203.1131636366005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

I did not get any compilation errors. I set $VOLUMIZER_DEBUG_LEVEL to 5 to = see all the debug info and I can see nothing wrong.

Well, maybe early ray termination is not a good idea for 3D texture mapping. Do you guys have a plan to implement GPU based ray casting in Volumizer?

-- Kevin

On 11/10/05, Praveen Bhaniramka <praveenb@sgi.com> wrote:
Not sure what is=20 going on. Do you get any errors from Volumizer about the shader compilation= ? If=20 the shader does not compile, Volumizer will give you an error.=20
 
Volumizer will=20 always use back-to-front slicing based on the transform matrices set by the= =20 application. So, mucking with the matrices might not really help. I will tr= y and=20 think about some other solution for you as well.
 
-=20 Praveen
-----Original Message-----
From: Kevin W= ang=20 [mailto:kwang22@gmail.com]
<= /span>
Sent: Thurs= day, November 10, 2005 1:17=20 AM
To: praveenb@sgi.com=
Subject: Re: Cg support in OpenGL=20 multipipe

Hi Praveen,

Thanks for your=20 ideas.

I have tried your second recommendation regarding interpola= tion=20 mode using the following GLSL program.

"vec3 coordinates, de= lta,=20 integal;\n"
"coordinates.s =3D volume_TexCoord.s *=20 volume_TexDims.x;\n"
"coordinates.t =3D volume_TexCoord.t *= =20 volume_TexDims.y;\n"
"coordinates.p =3D volume_TexCoord.p *= =20 volume_TexDims.z;\n"
"delta.s =3D floor(coordinates.s);\n&qu= ot;
"delta.t =3D=20 floor(coordinates.t);\n"
"delta.p =3D floor(coordinates.p);\= n"
"integal.s=20 =3D (delta.s ) / volume_TexDims.x;\n"
"integal.t =3D (delta= .t ) /=20 volume_TexDims.y;\n"
"integal.p =3D (delta.p ) / volume_Tex= Dims.z;\n"=20
"color =3D texture3D(volume,integal.stp);\n"

Origina= lly the code is=20
"color =3D texture3D(volume,volume_TexCoord.stp);\n"
Now the problem=20 is that nothing shows up in my program. Since I am new to GLSL so I wonde= r if=20 you can test this code for me. Thanks in advance.

As regard to emp= ty=20 space leaping, I think your idea is good but usually out data (maily medi= cal=20 imaging data) have very few empty spaces so I would not pursue in that=20 direction. Early ray termination uses different rendering order and that = is=20 really a problem. Do you think if it is possible to render the volume in = the=20 opposite direction so that the rendering order will be changed to front t= o=20 back in volumizer? this needs to change modelviewproject matrix and manip= ulate=20 the depth test. I have not thought carefully about this. and it can be to= o=20 complicated in practice.

-- Kevin



On 11/8/05, Praveen=20 Bhaniramka <praveenb@sgi.com>=20 wrote:
Kevin,
 
I am not sure if you can cha= nge the=20 interpolation filter in TMFragmentShader or not. You should try using t= he=20 callbacks and see if they do the right thing for you. Another option wo= uld=20 be to compute the "integral" texture coordinates in the fragm= ent shader and=20 then use them to sample the textures that you want to be NEAREST filter= ed.=20 You can do somehting like -
    vec3 = ;coordinates=20 =3D volume_TexCoord * volume_TexDims;
    vec3 delt= a =3D=20 fract(coordinates);
    vec3 inte= gal =3D=20 (coordinates - delta) / volume_TexDims;
 
Yeah... I am sure that there= are ways to=20 improve the texture rendering using early ray termination and empty spa= ce=20 leaping with Volumizer. You are right that 3D texture rendering is brut= e=20 force in the sense that it slices the complete volume and renders the d= ata.=20 One easy way to implement empty space leaping is to compute a bounding= =20 geometry of the volume data that you know is visible and "cut-out&= quot;, using=20 geometry,  the data that is not visible. Then use this bounding=20 geometry for rendering the volume data set. That should improve the=20 performance a bit. I am sure that early ray termination etc is also=20 possible,.. I just haven't thought about that a lot. One potential issu= e=20 there is that Volumizer currently does back-to-front rendering and earl= y ray=20 termination is typically useful for front-to-back rendering. Front-to-b= ack=20 rendering has other issues with embedded polygonal geometry in the same= =20 scene, etc.
 
Let me know if you have othe= r ideas or=20 questions.
 
- Praveen
 
-----Original Message-----
From: Kevin Wang [mai= lto: kwang22@gmail.com]=20
Sent: Wednesday, N= ovember 09, 2005 3:11 AM
To: = praveenb@sgi.com
Subject: Re: Cg support in=20 OpenGL multipipe

Hi Praveen,

Thanks for=20 your reply. I am using vzTMFragmentShader class, is it possible to ch= ange=20 interpolation mode for it?

Also I am thinking about ways to= =20 improve either quality or speed of volumizer. do you think it is poss= ible=20 to implement technique like early ray termination for volumizer so th= at=20 only a fraction of the slices need to be rendered ( when the opacity= =20 reaches 1 then set Z buffer and using depth test to by pass rendering= ) ?=20 As I understand, 3D texture mapping slices the volume and renders all= the=20 slices.

Regards,

-- Kevin

On 11/5/05, Praveen=20 Bhaniramka <praveenb@sgi.c= om>=20 wrote:=20
Hi Kevin,<= /div>
 
Currently, it is not pos= sible to=20 change the interpolation mode in Volumizer for the built-in shaders= =20 (LUT, Gradient, Tag, etc). The interpolation mode is set to be GL_L= INEAR=20 for all vzParameterVolumeTexture's and GL_NEAREST for all=20 vzParameterLookupTable's used in the shader.
 
However, if you are usin= g=20 vzTMFragmentProgram shader, Volumizer provides you callbacks for bi= nding=20 your various textures. In those callbacks, after you bind the volum= e=20 texture (by using the bindVolumeTextureCB function), you set the=20 interpolation modes using the glTexParameteri() commands.=20
 
- Praveen<= /div>
 
-----Original Message-----
From: Kevin Wang= =20 [mailto: kwang22@gmail.com]=20
Sent: Saturday= , November=20 05, 2005 1:51 AM
To: On 11/4/05, Praveen Bhaniramka <pr= aveenb@sgi.com >=20 wrote:=20
I am not sure if Cg = compiler=20 provides the option of converting GLSL to ARB_fragment_program.= =20
 =
- Praveen
-----Original Message-----
From: Kevin W= ang=20 [mailto:=20 kwang22@gmail.com]
Sent: Frid= ay, November=20 04, 2005 8:41 PM
To: praveenb@sgi.com=20
Subject: Re: Cg support in OpenGL=20 multipipe

Hi Praveen,

Thanks for your response. Yes, = I am=20 using Propack 3 and we dont anticipate a system upgrade withi= n the=20 next half year. since the code is still in development stage,= i=20 guess we can wait for a while for the upgrade.

Intere= sting=20 that Cg program can be convert into a ARB_Fragment_program. t= hen I=20 would assume that so does GLSL program. I will look into that= =20 matter.

Regards,

-- Kevin

On 11/4/05, Praveen Bhaniramka <
Hi Kevin,=
&n= bsp;
I am pretty sure= that OpenGL=20 Multipipe does not support Cg. The simple reason is that Pr= ism=20 does not support Cg and OpenGL Multipipe can only run on Pr= ism!=20 Actually, I got the following response from Guy, = who=20 is the tech lead on OMP.
&n= bsp;
"OMP will support GLSL onl= y with Propack=20 4 SP3. About performance improvement with OMP,= if=20 the app is fill limited (as I assume it should= be)=20 then OMP should scale = the=20 perfirmance."
&n= bsp;
I would imagine = that your=20 Prism is currently running ProPack 3.x. So in order to= use=20 GLSL, you would need to use PP4 SP3 (which will be=20 available in December AFAIK). For now, your best bet is to = use=20 ARB_fragment_program in Volumizer. You can still=20 use Cg by running the Cg compiler and passing it = your=20 Cg program and asking it to convert the Cg program to=20 ARB_fragment_program. You can then pass the fragment progra= m to=20 Volumizer directly.
&n= bsp;
(Sorry for the d= elay in=20 replying... I was travelling last week and earlier thi= s=20 week)
&n= bsp;
hth,
Praveen
  &nbs= p;=20
-----Original Message-----
From: Kevin Wan= g=20 [mailto:kwang22@gmai= l.com]
Sent: Monday,=20 October 24, 2005 9:57 PM
To: Saurabh Gupta; Pra= veen=20 Bhaniramka
Subject: Cg support in OpenGL=20 multipipe
Importance: Low

H= i=20 Saurabh and Praveen,

Do you guys know that if Open= GL=20 multipipe supports Cg shading language? We have a custom= =20 developed raycasting volume rendering software package wh= ich=20 uses opengl shading language. Praveen said that OMP doesn= ot=20 support OpenGL shading language so I was wondering if it= =20 supports Cg or other high level shading language. and if= =20 possible, will the next release support OpenGL shading=20 language?

Regards,

--=20 Kevin

<= /span>

<= /blockquote>



------=_Part_34793_4812203.1131636366005-- From info-volumizer-owner@els.sgi.com Thu Nov 10 12:41:00 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jAAKeCLn8920005; Thu, 10 Nov 2005 12:40:12 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jAAKcDJT8940048 for ; Thu, 10 Nov 2005 12:38:14 -0800 (PST) Received: from mtv-atc-013e--n.corp.sgi.com (mtv-atc-013e--n.corp.sgi.com [192.26.78.50]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAAKfeAQ70324239 for ; Thu, 10 Nov 2005 12:41:40 -0800 (PST) Received: from praveenlaptop (134.14.90.125 [134.14.90.125]) by mtv-atc-013e--n.corp.sgi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WL5VAY8X; Thu, 10 Nov 2005 12:38:12 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] Re: GLSL Shader in Volumizer Date: Fri, 11 Nov 2005 02:07:57 +0530 Message-ID: <056b01c5e636$a6d3ad80$2d000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com I wonder what could be wrong with the GLSL shader. It seems pretty simple. Can you try using vector operations instead of scalar ones that you are using right now? So, your shader might look like - "vec3 coordinates, delta, integal;\n" "coordinates = vec3(volume_TexCoord) * volume_TexDims;\n" "delta = floor(coordinates);\n" "integal = (delta) / volume_TexDims;\n" "color = texture3D(volume,integal.stp);\n" This should also be more efficient and hopefully less liable to shader compilation issues in the drivers. No, we haven't implemented GPU-based ray casting in Volumizer yet. There are issues with the technique which might not allow it to work in real applications, e.g. mixing polygonal geometry with the rendering, etc. It is definitely something that we are thinking of doing in the future, but so far, GPU ray casting is a good research prototype IMHO. Cheers, Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Thursday, November 10, 2005 8:56 PM To: praveenb@sgi.com; info-volumizer@els.sgi.com Subject: [info-volumizer] Re: Cg support in OpenGL multipipe Hi, I did not get any compilation errors. I set $VOLUMIZER_DEBUG_LEVEL to 5 to see all the debug info and I can see nothing wrong. Well, maybe early ray termination is not a good idea for 3D texture mapping. Do you guys have a plan to implement GPU based ray casting in Volumizer? -- Kevin On 11/10/05, Praveen Bhaniramka wrote: Not sure what is going on. Do you get any errors from Volumizer about the shader compilation? If the shader does not compile, Volumizer will give you an error. Volumizer will always use back-to-front slicing based on the transform matrices set by the application. So, mucking with the matrices might not really help. I will try and think about some other solution for you as well. - Praveen -----Original Message----- From: Kevin Wang [mailto:kwang22@gmail.com] Sent: Thursday, November 10, 2005 1:17 AM To: praveenb@sgi.com Subject: Re: Cg support in OpenGL multipipe Hi Praveen, Thanks for your ideas. I have tried your second recommendation regarding interpolation mode using the following GLSL program. "vec3 coordinates, delta, integal;\n" "coordinates.s = volume_TexCoord.s * volume_TexDims.x;\n" "coordinates.t = volume_TexCoord.t * volume_TexDims.y;\n" "coordinates.p = volume_TexCoord.p * volume_TexDims.z;\n" "delta.s = floor(coordinates.s);\n" "delta.t = floor(coordinates.t);\n" "delta.p = floor(coordinates.p);\n" "integal.s = (delta.s ) / volume_TexDims.x;\n" "integal.t = (delta.t ) / volume_TexDims.y;\n" "integal.p = (delta.p ) / volume_TexDims.z;\n" "color = texture3D(volume,integal.stp);\n" Originally the code is "color = texture3D(volume,volume_TexCoord.stp);\n" Now the problem is that nothing shows up in my program. Since I am new to GLSL so I wonder if you can test this code for me. Thanks in advance. As regard to empty space leaping, I think your idea is good but usually out data (maily medical imaging data) have very few empty spaces so I would not pursue in that direction. Early ray termination uses different rendering order and that is really a problem. Do you think if it is possible to render the volume in the opposite direction so that the rendering order will be changed to front to back in volumizer? this needs to change modelviewproject matrix and manipulate the depth test. I have not thought carefully about this. and it can be too complicated in practice. -- Kevin On 11/8/05, Praveen Bhaniramka wrote: Kevin, I am not sure if you can change the interpolation filter in TMFragmentShader or not. You should try using the callbacks and see if they do the right thing for you. Another option would be to compute the "integral" texture coordinates in the fragment shader and then use them to sample the textures that you want to be NEAREST filtered. You can do somehting like - vec3 coordinates = volume_TexCoord * volume_TexDims; vec3 delta = fract(coordinates); vec3 integal = (coordinates - delta) / volume_TexDims; Yeah... I am sure that there are ways to improve the texture rendering using early ray termination and empty space leaping with Volumizer. You are right that 3D texture rendering is brute force in the sense that it slices the complete volume and renders the data. One easy way to implement empty space leaping is to compute a bounding geometry of the volume data that you know is visible and "cut-out", using geometry, the data that is not visible. Then use this bounding geometry for rendering the volume data set. That should improve the performance a bit. I am sure that early ray termination etc is also possible,.. I just haven't thought about that a lot. One potential issue there is that Volumizer currently does back-to-front rendering and early ray termination is typically useful for front-to-back rendering. Front-to-back rendering has other issues with embedded polygonal geometry in the same scene, etc. Let me know if you have other ideas or questions. - Praveen -----Original Message----- From: Kevin Wang [mailto: kwang22@gmail.com] Sent: Wednesday, November 09, 2005 3:11 AM To: praveenb@sgi.com Subject: Re: Cg support in OpenGL multipipe Hi Praveen, Thanks for your reply. I am using vzTMFragmentShader class, is it possible to change interpolation mode for it? Also I am thinking about ways to improve either quality or speed of volumizer. do you think it is possible to implement technique like early ray termination for volumizer so that only a fraction of the slices need to be rendered ( when the opacity reaches 1 then set Z buffer and using depth test to by pass rendering) ? As I understand, 3D texture mapping slices the volume and renders all the slices. Regards, -- Kevin On 11/5/05, Praveen Bhaniramka wrote: Hi Kevin, Currently, it is not possible to change the interpolation mode in Volumizer for the built-in shaders (LUT, Gradient, Tag, etc). The interpolation mode is set to be GL_LINEAR for all vzParameterVolumeTexture's and GL_NEAREST for all vzParameterLookupTable's used in the shader. However, if you are using vzTMFragmentProgram shader, Volumizer provides you callbacks for binding your various textures. In those callbacks, after you bind the volume texture (by using the bindVolumeTextureCB function), you set the interpolation modes using the glTexParameteri() commands. - Praveen -----Original Message----- From: Kevin Wang [mailto: kwang22@gmail.com] Sent: Saturday, November 05, 2005 1:51 AM To: praveenb@sgi.com Subject: Re: Cg support in OpenGL multipipe Praveen, Sorry I did not mean to use Cg compiler. I mean similarly it would apply to a GLSL compiler. anyway, it is not urgent now. I have got a new question for you now. I know volumizer uses 3D texture mapping technique. and when using it, usually we need to specify the interpolation mode during the texture setup. I wonder if there is a way i can change this mode during rendering with Volumizer? below is the OpenGL code to set up the interpolation mode. I want to use nearest neighbor mode in certain situations. glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MAX_FILTER, GL_LINEAR); Look forward to your response. Thanks. -- Kevin On 11/4/05, Praveen Bhaniramka wrote: I am not sure if Cg compiler provides the option of converting GLSL to ARB_fragment_program. - Praveen -----Original Message----- From: Kevin Wang [mailto: kwang22@gmail.com] Sent: Friday, November 04, 2005 8:41 PM To: praveenb@sgi.com Subject: Re: Cg support in OpenGL multipipe Hi Praveen, Thanks for your response. Yes, I am using Propack 3 and we dont anticipate a system upgrade within the next half year. since the code is still in development stage, i guess we can wait for a while for the upgrade. Interesting that Cg program can be convert into a ARB_Fragment_program. then I would assume that so does GLSL program. I will look into that matter. Regards, -- Kevin On 11/4/05, Praveen Bhaniramka wrote: Hi Kevin, I am pretty sure that OpenGL Multipipe does not support Cg. The simple reason is that Prism does not support Cg and OpenGL Multipipe can only run on Prism! Actually, I got the following response from Guy, who is the tech lead on OMP. "OMP will support GLSL only with Propack 4 SP3. About performance improvement with OMP, if the app is fill limited (as I assume it should be) then OMP should scale the perfirmance." I would imagine that your Prism is currently running ProPack 3.x. So in order to use GLSL, you would need to use PP4 SP3 (which will be available in December AFAIK). For now, your best bet is to use ARB_fragment_program in Volumizer. You can still use Cg by running the Cg compiler and passing it your Cg program and asking it to convert the Cg program to ARB_fragment_program. You can then pass the fragment program to Volumizer directly. (Sorry for the delay in replying... I was travelling last week and earlier this week) hth, Praveen -----Original Message----- From: Kevin Wang [mailto:kwang22@gmail.com] Sent: Monday, October 24, 2005 9:57 PM To: Saurabh Gupta; Praveen Bhaniramka Subject: Cg support in OpenGL multipipe Importance: Low Hi Saurabh and Praveen, Do you guys know that if OpenGL multipipe supports Cg shading language? We have a custom developed raycasting volume rendering software package which uses opengl shading language. Praveen said that OMP doesnot support OpenGL shading language so I was wondering if it supports Cg or other high level shading language. and if possible, will the next release support OpenGL shading language? Regards, -- Kevin From info-volumizer-owner@els.sgi.com Tue Nov 15 09:25:35 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jAFHNusU9055987; Tue, 15 Nov 2005 09:23:56 -0800 (PST) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jAFHInJT9020599 for ; Tue, 15 Nov 2005 09:18:50 -0800 (PST) Received: by xproxy.gmail.com with SMTP id s17so1514829wxc for ; Tue, 15 Nov 2005 09:18:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=i/0BSJXZDfH3MTsgwWpQxXC+Tys7jVu4GaMjPbVX1EY6Wy1Kx9KVOB4P2Ii3S+1k5gUyz9T4DJ7HG3z8j9oZ0U0UEpVyzXCwXCpgHcr4C9WruYVF69tybYVxR2a1RWkpw315BKBmTAvtYfRLvT0bAIV8e+tcH0OuqpWC0Jwnppw= Received: by 10.65.222.11 with SMTP id z11mr7612672qbq; Tue, 15 Nov 2005 09:18:48 -0800 (PST) Received: by 10.65.155.20 with HTTP; Tue, 15 Nov 2005 09:18:48 -0800 (PST) Message-ID: Date: Tue, 15 Nov 2005 12:18:48 -0500 From: Kevin Wang To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] Re: GLSL Shader in Volumizer In-Reply-To: <056b01c5e636$a6d3ad80$2d000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21599_10630915.1132075128250" References: <056b01c5e636$a6d3ad80$2d000f86@asiapac.sgi.com> Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com ------=_Part_21599_10630915.1132075128250 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen, I tried your code, still gives me linear interpolation effect. Also you hav= e mentioned that using vzTMFragmentProgram I can set callbacks and change the interpolation mode there. but you are not sure about vzTMFragmentShader. I checked sgi documentation. It seems there is no way to set callback for vzTMFragmentShader. Just want to let you know that. Regards, -- Kevin On 11/10/05, Praveen Bhaniramka wrote: > > I wonder what could be wrong with the GLSL shader. It seems pretty > simple. Can you try using vector operations instead of scalar ones that > you are using right now? So, your shader might look like - > > "vec3 coordinates, delta, integal;\n" > "coordinates =3D vec3(volume_TexCoord) * volume_TexDims;\n" > "delta =3D floor(coordinates);\n" > "integal =3D (delta) / volume_TexDims;\n" > "color =3D texture3D(volume,integal.stp);\n" > > This should also be more efficient and hopefully less liable to shader > compilation issues in the drivers. > > No, we haven't implemented GPU-based ray casting in Volumizer yet. There > are issues with the technique which might not allow it to work in real > applications, e.g. mixing polygonal geometry with the rendering, etc. It > is definitely something that we are thinking of doing in the future, but > so far, GPU ray casting is a good research prototype IMHO. > > Cheers, > Praveen > > -----Original Message----- > From: owner-info-volumizer@els.sgi.com > [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang > Sent: Thursday, November 10, 2005 8:56 PM > To: praveenb@sgi.com; info-volumizer@els.sgi.com > Subject: [info-volumizer] Re: Cg support in OpenGL multipipe > > > Hi, > > I did not get any compilation errors. I set $VOLUMIZER_DEBUG_LEVEL to 5 > to see all the debug info and I can see nothing wrong. > > Well, maybe early ray termination is not a good idea for 3D texture > mapping. Do you guys have a plan to implement GPU based ray casting in > Volumizer? > > -- Kevin > > > On 11/10/05, Praveen Bhaniramka wrote: > Not sure what is going on. Do you get any errors from Volumizer about > the shader compilation? If the shader does not compile, Volumizer will > give you an error. > > Volumizer will always use back-to-front slicing based on the transform > matrices set by the application. So, mucking with the matrices might not > really help. I will try and think about some other solution for you as > well. > > - Praveen > -----Original Message----- > From: Kevin Wang [mailto:kwang22@gmail.com] > > Sent: Thursday, November 10, 2005 1:17 AM > To: praveenb@sgi.com > Subject: Re: Cg support in OpenGL multipipe > > > Hi Praveen, > > Thanks for your ideas. > > I have tried your second recommendation regarding interpolation mode > using the following GLSL program. > > "vec3 coordinates, delta, integal;\n" > "coordinates.s =3D volume_TexCoord.s * volume_TexDims.x;\n" > "coordinates.t =3D volume_TexCoord.t * volume_TexDims.y;\n" > "coordinates.p =3D volume_TexCoord.p * volume_TexDims.z;\n" > "delta.s =3D floor(coordinates.s);\n" > "delta.t =3D floor(coordinates.t);\n" > "delta.p =3D floor(coordinates.p);\n" > "integal.s =3D (delta.s ) / volume_TexDims.x;\n" > "integal.t =3D (delta.t ) / volume_TexDims.y;\n" > "integal.p =3D (delta.p ) / volume_TexDims.z;\n" > "color =3D texture3D(volume,integal.stp);\n" > > Originally the code is > "color =3D texture3D(volume,volume_TexCoord.stp);\n" > > Now the problem is that nothing shows up in my program. Since I am new > to GLSL so I wonder if you can test this code for me. Thanks in advance. > > As regard to empty space leaping, I think your idea is good but usually > out data (maily medical imaging data) have very few empty spaces so I > would not pursue in that direction. Early ray termination uses different > rendering order and that is really a problem. Do you think if it is > possible to render the volume in the opposite direction so that the > rendering order will be changed to front to back in volumizer? this > needs to change modelviewproject matrix and manipulate the depth test. I > have not thought carefully about this. and it can be too complicated in > practice. > > -- Kevin > > > > > On 11/8/05, Praveen Bhaniramka wrote: > Kevin, > > I am not sure if you can change the interpolation filter in > TMFragmentShader or not. You should try using the callbacks and see if > they do the right thing for you. Another option would be to compute the > "integral" texture coordinates in the fragment shader and then use them > to sample the textures that you want to be NEAREST filtered. You can do > somehting like - > vec3 coordinates =3D volume_TexCoord * volume_TexDims; > vec3 delta =3D fract(coordinates); > vec3 integal =3D (coordinates - delta) / volume_TexDims; > > Yeah... I am sure that there are ways to improve the texture rendering > using early ray termination and empty space leaping with Volumizer. You > are right that 3D texture rendering is brute force in the sense that it > slices the complete volume and renders the data. One easy way to > implement empty space leaping is to compute a bounding geometry of the > volume data that you know is visible and "cut-out", using geometry, the > data that is not visible. Then use this bounding geometry for rendering > the volume data set. That should improve the performance a bit. I am > sure that early ray termination etc is also possible,.. I just haven't > thought about that a lot. One potential issue there is that Volumizer > currently does back-to-front rendering and early ray termination is > typically useful for front-to-back rendering. Front-to-back rendering > has other issues with embedded polygonal geometry in the same scene, > etc. > > Let me know if you have other ideas or questions. > > - Praveen > > -----Original Message----- > From: Kevin Wang [mailto: kwang22@gmail.com] > > Sent: Wednesday, November 09, 2005 3:11 AM > To: praveenb@sgi.com > Subject: Re: Cg support in OpenGL multipipe > > > Hi Praveen, > > Thanks for your reply. I am using vzTMFragmentShader class, is it > possible to change interpolation mode for it? > > Also I am thinking about ways to improve either quality or speed of > volumizer. do you think it is possible to implement technique like early > ray termination for volumizer so that only a fraction of the slices need > to be rendered ( when the opacity reaches 1 then set Z buffer and using > depth test to by pass rendering) ? As I understand, 3D texture mapping > slices the volume and renders all the slices. > > Regards, > > -- Kevin > > > On 11/5/05, Praveen Bhaniramka wrote: > Hi Kevin, > > Currently, it is not possible to change the interpolation mode in > Volumizer for the built-in shaders (LUT, Gradient, Tag, etc). The > interpolation mode is set to be GL_LINEAR for all > vzParameterVolumeTexture's and GL_NEAREST for all > vzParameterLookupTable's used in the shader. > > However, if you are using vzTMFragmentProgram shader, Volumizer provides > you callbacks for binding your various textures. In those callbacks, > after you bind the volume texture (by using the bindVolumeTextureCB > function), you set the interpolation modes using the glTexParameteri() > commands. > > - Praveen > > -----Original Message----- > From: Kevin Wang [mailto: kwang22@gmail.com] > > Sent: Saturday, November 05, 2005 1:51 AM > To: praveenb@sgi.com > Subject: Re: Cg support in OpenGL multipipe > > > Praveen, > > Sorry I did not mean to use Cg compiler. I mean similarly it would apply > to a GLSL compiler. anyway, it is not urgent now. > > I have got a new question for you now. I know volumizer uses 3D texture > mapping technique. and when using it, usually we need to specify the > interpolation mode during the texture setup. I wonder if there is a way > i can change this mode during rendering with Volumizer? below is the > OpenGL code to set up the interpolation mode. I want to use nearest > neighbor mode in certain situations. > > glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MIN_FILTER, GL_LINEAR); > glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MAX_FILTER, GL_LINEAR); > > Look forward to your response. Thanks. > > -- Kevin > > > On 11/4/05, Praveen Bhaniramka wrote: > I am not sure if Cg compiler provides the option of converting GLSL to > ARB_fragment_program. > > - Praveen > -----Original Message----- > From: Kevin Wang [mailto: kwang22@gmail.com] > > Sent: Friday, November 04, 2005 8:41 PM > To: praveenb@sgi.com > Subject: Re: Cg support in OpenGL multipipe > > > Hi Praveen, > > Thanks for your response. Yes, I am using Propack 3 and we dont > anticipate a system upgrade within the next half year. since the code is > still in development stage, i guess we can wait for a while for the > upgrade. > > Interesting that Cg program can be convert into a ARB_Fragment_program. > then I would assume that so does GLSL program. I will look into that > matter. > > Regards, > > -- Kevin > > > On 11/4/05, Praveen Bhaniramka wrote: > Hi Kevin, > > I am pretty sure that OpenGL Multipipe does not support Cg. The simple > reason is that Prism does not support Cg and OpenGL Multipipe can only > run on Prism! Actually, I got the following response from Guy, who is > the tech lead on OMP. > > "OMP will support GLSL only with Propack 4 SP3. About performance > improvement with OMP, if the app is fill limited (as I assume it should > be) then OMP should scale the perfirmance." > > I would imagine that your Prism is currently running ProPack 3.x. So in > order to use GLSL, you would need to use PP4 SP3 (which will be > available in December AFAIK). For now, your best bet is to use > ARB_fragment_program in Volumizer. You can still use Cg by running the > Cg compiler and passing it your Cg program and asking it to convert the > Cg program to ARB_fragment_program. You can then pass the fragment > program to Volumizer directly. > > (Sorry for the delay in replying... I was travelling last week and > earlier this week) > > hth, > Praveen > > -----Original Message----- > From: Kevin Wang [mailto:kwang22@gmail.com] > Sent: Monday, October 24, 2005 9:57 PM > To: Saurabh Gupta; Praveen Bhaniramka > Subject: Cg support in OpenGL multipipe > Importance: Low > > > Hi Saurabh and Praveen, > > Do you guys know that if OpenGL multipipe supports Cg shading language? > We have a custom developed raycasting volume rendering software package > which uses opengl shading language. Praveen said that OMP doesnot > support OpenGL shading language so I was wondering if it supports Cg or > other high level shading language. and if possible, will the next > release support OpenGL shading language? > > Regards, > > -- Kevin > > ------=_Part_21599_10630915.1132075128250 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Praveen,

I tried your code, still gives me linear interpolation effect. Also you have mentioned that using vzTMFragmentProgram I can set callbacks and change the interpolation mode there. but you are not sure about vzTMFragmentShader. I checked sgi documentation. It seems there is no way to set callback for vzTMFragmentShader. Just want to let you know that.

Regards,

-- Kevin

On 11/10/05, Praveen Bhaniramka <praveenb@sgi.com> wrote:
I wonder what could be wrong with the GLSL shader. It seems pretty
simpl= e. Can you try using vector operations instead of scalar ones that
you a= re using right now? So, your shader might look like -

"vec3 coo= rdinates, delta, integal;\n"
"coordinates =3D vec3(volume_TexCoord) * volume_TexDims;\n""delta =3D floor(coordinates);\n"
"integal =3D (delta) = / volume_TexDims;\n"
"color =3D texture3D(volume,integal.stp);= \n"

This should also be more efficient and hopefully less liable to sha= der
compilation issues in the drivers.

No, we haven't implemented= GPU-based ray casting in Volumizer yet. There
are issues with the techn= ique which might not allow it to work in real
applications, e.g. mixing polygonal geometry with the rendering, etc. I= t
is definitely something that we are thinking of doing in the future, b= ut
so far, GPU ray casting is a good research prototype IMHO.

Cheers,
Praveen

-----Original Message-----
From: owner-info-volumizer@els.sgi.com=
[mailto:owner-info-= volumizer@els.sgi.com ] On Behalf Of Kevin Wang
Sent: Thursday, November 10, 2005 8:56 PM<= br>To: praveenb@sgi.com; info-volumizer@els.sgi.com
Subje= ct: [info-volumizer] Re: Cg support in OpenGL multipipe


Hi,

I did not get any compilation errors. I set $VOLUMIZ= ER_DEBUG_LEVEL to 5
to see all the debug info and I can see nothing wron= g.

Well, maybe early ray termination is not a good idea for 3D textu= re
mapping. Do you guys have a plan to implement GPU based ray casting in<= br>Volumizer?

-- Kevin


On 11/10/05, Praveen Bhaniramka &l= t;praveenb@sgi.com> wrote:
Not sure what is going on. Do you get any errors from Volumizer about
th= e shader compilation? If the shader does not compile, Volumizer will
giv= e you an error.

Volumizer will always use back-to-front slicing base= d on the transform
matrices set by the application. So, mucking with the matrices might no= t
really help. I will try and think about some other solution for you as=
well.

- Praveen
-----Original Message-----
From: Kevin Wan= g [mailto: kwang22@gmail.com]

Sent: Th= ursday, November 10, 2005 1:17 AM
To: praveenb@sgi.com
Subject: Re: Cg support in OpenGL multipipe

Hi Praveen,

Thanks for your ideas.

I have tried your seco= nd recommendation regarding interpolation mode
using the following GLSL = program.

"vec3 coordinates, delta, integal;\n"
" coordinates.s =3D volume_TexCoord.s * volume_TexDims.x;\n"
"co= ordinates.t =3D volume_TexCoord.t * volume_TexDims.y;\n"
"coor= dinates.p =3D volume_TexCoord.p * volume_TexDims.z;\n"
"delta.= s =3D floor( coordinates.s);\n"
"delta.t =3D floor(coordinates.t);\n"<= br>"delta.p =3D floor(coordinates.p);\n"
"integal.s =3D (= delta.s ) / volume_TexDims.x;\n"
"integal.t =3D (delta.t ) / v= olume_TexDims.y;\n"
"integal.p =3D (delta.p ) / volume_TexDims.z;\n"
"col= or =3D texture3D(volume,integal.stp);\n"

Originally the code is=
"color =3D texture3D(volume,volume_TexCoord.stp);\n"

N= ow the problem is that nothing shows up in my program. Since I am new
to GLSL so I wonder if you can test this code for me. Thanks in advance= .

As regard to empty space leaping, I think your idea is good but us= ually
out data (maily medical imaging data) have very few empty spaces s= o I
would not pursue in that direction. Early ray termination uses differen= t
rendering order and that is really a problem. Do you think if it ispossible to render the volume in the opposite direction so that the
rendering order will be changed to front to back in volumizer? this
need= s to change modelviewproject matrix and manipulate the depth test. I
hav= e not thought carefully about this. and it can be too complicated in
practice.

-- Kevin




On 11/8/05, Praveen Bhaniramka= <praveenb@sgi.com> wrote:Kevin,

I am not sure if you can change the interpolation filter in
TMFragmentShader or not. You should try using the callbacks and see if<= br>they do the right thing for you. Another option would be to compute the<= br>"integral" texture coordinates in the fragment shader and then= use them
to sample the textures that you want to be NEAREST filtered. You can do=
somehting like -
    vec3 coordinates =3D volume= _TexCoord * volume_TexDims;
    vec3 delta =3D fract= (coordinates);
    vec3 integal =3D (coordinates - d= elta) / volume_TexDims;

Yeah... I am sure that there are ways to improve the texture render= ing
using early ray termination and empty space leaping with Volumizer. = You
are right that 3D texture rendering is brute force in the sense that= it
slices the complete volume and renders the data. One easy way to
imp= lement empty space leaping is to compute a bounding geometry of the
volu= me data that you know is visible and "cut-out", using geometry,&n= bsp; the
data that is not visible. Then use this bounding geometry for rendering=
the volume data set. That should improve the performance a bit. I amsure that early ray termination etc is also possible,.. I just haven't
thought about that a lot. One potential issue there is that Volumizercurrently does back-to-front rendering and early ray termination is
ty= pically useful for front-to-back rendering. Front-to-back rendering
has other issues with embedded polygonal geometry in the same scene,
etc= .

Let me know if you have other ideas or questions.

- Praveen=

-----Original Message-----
From: Kevin Wang [mailto: kwang22@gmail.com]

Sent: Wednesday, November 09, 2005 3:11 AMTo: praveenb@sgi.com
Subject: R= e: Cg support in OpenGL multipipe


Hi Praveen,

Thanks for = your reply. I am using vzTMFragmentShader class, is it
possible to change interpolation mode for it?

Also I am thinking= about ways to improve either quality or speed of
volumizer. do you thin= k it is possible to implement technique like early
ray termination for v= olumizer so that only a fraction of the slices need
to be rendered ( when the opacity reaches 1 then set Z buffer and using=
depth test to by pass rendering) ? As I understand, 3D texture mapping<= br>slices the volume and renders all the slices.

Regards,

-- Kevin


On 11/5/05, Praveen Bhaniramka <praveenb@sgi.com> wrote:
Hi Kevin,

Current= ly, it is not possible to change the interpolation mode in
Volumizer for= the built-in shaders (LUT, Gradient, Tag, etc). The
interpolation mode is set to be GL_LINEAR for all
vzParameterVolumeT= exture's and GL_NEAREST for all
vzParameterLookupTable's used in the sha= der.

However, if you are using vzTMFragmentProgram shader, Volumizer= provides
you callbacks for binding your various textures. In those callbacks,after you bind the volume texture (by using the bindVolumeTextureCB
fun= ction), you set the interpolation modes using the glTexParameteri()
commands.

- Praveen

-----Original Message-----
From: Kevin= Wang [mailto: kwang22@gmail.com]<= br>
Sent: Saturday, November 05, 2005 1:51 AM
To: praveenb@sgi.com
Subject: Re: Cg support in OpenGL multipipe

=
Praveen,

Sorry I did not mean to use Cg compiler. I mean similar= ly it would apply
to a GLSL compiler. anyway, it is not urgent now.

I have got a new question for you now. I know volumizer uses 3D texture=
mapping technique. and when using it, usually we need to specify theinterpolation mode during the texture setup. I wonder if there is a way
i can change this mode during rendering with Volumizer? below is theOpenGL code to set up the interpolation mode. I want to use nearest
nei= ghbor mode in certain situations.

glTexParameteri(GL_TEXTURE_3D_EXT,= GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MAX_FILTER, GL_LINEAR);
Look forward to your response. Thanks.

-- Kevin


On = 11/4/05, Praveen Bhaniramka <praveen= b@sgi.com > wrote:
I am not sure if Cg compiler provides the option of con= verting GLSL to
ARB_fragment_program.

- Praveen
-----Original = Message-----
From: Kevin Wang [mailto: kwang22@gmail.com]

Sent: Friday, November 04, 2005 8:41 PM
To= : praveenb@sgi.com
Subject: Re: = Cg support in OpenGL multipipe


Hi Praveen,

Thanks for you= r response. Yes, I am using Propack 3 and we dont
anticipate a system upgrade within the next half year. since the code i= s
still in development stage, i guess we can wait for a while for theupgrade.

Interesting that Cg program can be convert into a ARB_Frag= ment_program.
then I would assume that so does GLSL program. I will look into thatmatter.

Regards,

-- Kevin


On 11/4/05, Praveen Bha= niramka <praveenb@sgi.com > w= rote:
Hi Kevin,

I am pretty sure that OpenGL Multipipe does not suppor= t Cg. The simple
reason is that Prism does not support Cg and OpenGL Mul= tipipe can only
run on Prism! Actually, I got the following response fro= m Guy, who is
the tech lead on OMP.

"OMP will support GLSL only with Prop= ack 4 SP3. About performance
improvement with OMP, if the app is fill li= mited (as I assume it should
be) then OMP should scale the perfirmance.&= quot;

I would imagine that your Prism is currently running ProPack 3.x. S= o in
order to use GLSL, you would need to use PP4 SP3 (which will be
= available in December AFAIK). For now, your best bet is to use
ARB_fragm= ent_program in Volumizer. You can still use Cg by running the
Cg compiler and passing it your Cg program and asking it to convert the=
Cg program to ARB_fragment_program. You can then pass the fragment
p= rogram to Volumizer directly.

(Sorry for the delay in replying... I = was travelling last week and
earlier this week)

hth,
Praveen

-----Original Message-= ----
From: Kevin Wang [mailto:kwang= 22@gmail.com]
Sent: Monday, October 24, 2005 9:57 PM
To: Saurabh = Gupta; Praveen Bhaniramka
Subject: Cg support in OpenGL multipipe
Importance: Low


H= i Saurabh and Praveen,

Do you guys know that if OpenGL multipipe sup= ports Cg shading language?
We have a custom developed raycasting volume = rendering software package
which uses opengl shading language. Praveen said that OMP doesnot
su= pport OpenGL shading language so I was wondering if it supports Cg or
ot= her high level shading language. and if possible, will the next
release = support OpenGL shading language?

Regards,

-- Kevin


------=_Part_21599_10630915.1132075128250-- From info-volumizer-owner@els.sgi.com Tue Nov 15 14:21:24 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jAFMKSJ09018224; Tue, 15 Nov 2005 14:20:28 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jAFMIdJT9046688 for ; Tue, 15 Nov 2005 14:18:39 -0800 (PST) Received: from mtv-atc-013e--n.corp.sgi.com (mtv-atc-013e--n.corp.sgi.com [192.26.78.50]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAFMM9AQ72025034 for ; Tue, 15 Nov 2005 14:22:09 -0800 (PST) Received: from praveenlaptop (mtv-vpn-sw-corp-0-117.corp.sgi.com [134.15.0.117]) by mtv-atc-013e--n.corp.sgi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id W52C4D7Z; Tue, 15 Nov 2005 14:18:38 -0800 From: "Praveen Bhaniramka" To: Subject: RE: [info-volumizer] Re: GLSL Shader in Volumizer Date: Wed, 16 Nov 2005 03:48:38 +0530 Message-ID: <000d01c5ea32$879aca20$75000f86@asiapac.sgi.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C5EA60.A1530620" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C5EA60.A1530620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Kevin, It is strange that the GLSL shader gives you linear interpolation even after rounding the texture coordinates to the nearest neighbour texel's coordinates. I guess, you might need to do some more debugging to make sure that the texture coordinates are being computed correctly. One simple way is to output the texture coordinates to the screen and see if they look like they are nearest neighbour or linear interpolated. Yeah... I did a quick check as well and it does not look like we provide any way to specify GL texture parameter settings when using TMFragmentShader class. - Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com] On Behalf Of Kevin Wang Sent: Tuesday, November 15, 2005 10:49 PM To: info-volumizer@els.sgi.com Subject: Re: [info-volumizer] Re: GLSL Shader in Volumizer Hi Praveen, I tried your code, still gives me linear interpolation effect. Also you have mentioned that using vzTMFragmentProgram I can set callbacks and change the interpolation mode there. but you are not sure about vzTMFragmentShader. I checked sgi documentation. It seems there is no way to set callback for vzTMFragmentShader. Just want to let you know that. Regards, -- Kevin On 11/10/05, Praveen Bhaniramka wrote: I wonder what could be wrong with the GLSL shader. It seems pretty simple. Can you try using vector operations instead of scalar ones that you are using right now? So, your shader might look like - "vec3 coordinates, delta, integal;\n" "coordinates = vec3(volume_TexCoord) * volume_TexDims;\n" "delta = floor(coordinates);\n" "integal = (delta) / volume_TexDims;\n" "color = texture3D(volume,integal.stp);\n" This should also be more efficient and hopefully less liable to shader compilation issues in the drivers. No, we haven't implemented GPU-based ray casting in Volumizer yet. There are issues with the technique which might not allow it to work in real applications, e.g. mixing polygonal geometry with the rendering, etc. It is definitely something that we are thinking of doing in the future, but so far, GPU ray casting is a good research prototype IMHO. Cheers, Praveen -----Original Message----- From: owner-info-volumizer@els.sgi.com [mailto:owner-info-volumizer@els.sgi.com ] On Behalf Of Kevin Wang Sent: Thursday, November 10, 2005 8:56 PM To: praveenb@sgi.com; info-volumizer@els.sgi.com Subject: [info-volumizer] Re: Cg support in OpenGL multipipe Hi, I did not get any compilation errors. I set $VOLUMIZER_DEBUG_LEVEL to 5 to see all the debug info and I can see nothing wrong. Well, maybe early ray termination is not a good idea for 3D texture mapping. Do you guys have a plan to implement GPU based ray casting in Volumizer? -- Kevin On 11/10/05, Praveen Bhaniramka wrote: Not sure what is going on. Do you get any errors from Volumizer about the shader compilation? If the shader does not compile, Volumizer will give you an error. Volumizer will always use back-to-front slicing based on the transform matrices set by the application. So, mucking with the matrices might not really help. I will try and think about some other solution for you as well. - Praveen -----Original Message----- From: Kevin Wang [mailto: kwang22@gmail.com] Sent: Thursday, November 10, 2005 1:17 AM To: praveenb@sgi.com Subject: Re: Cg support in OpenGL multipipe Hi Praveen, Thanks for your ideas. I have tried your second recommendation regarding interpolation mode using the following GLSL program. "vec3 coordinates, delta, integal;\n" " coordinates.s = volume_TexCoord.s * volume_TexDims.x;\n" "coordinates.t = volume_TexCoord.t * volume_TexDims.y;\n" "coordinates.p = volume_TexCoord.p * volume_TexDims.z;\n" "delta.s = floor( coordinates.s);\n" "delta.t = floor(coordinates.t);\n" "delta.p = floor(coordinates.p);\n" "integal.s = (delta.s ) / volume_TexDims.x;\n" "integal.t = (delta.t ) / volume_TexDims.y;\n" "integal.p = (delta.p ) / volume_TexDims.z;\n" "color = texture3D(volume,integal.stp);\n" Originally the code is "color = texture3D(volume,volume_TexCoord.stp);\n" Now the problem is that nothing shows up in my program. Since I am new to GLSL so I wonder if you can test this code for me. Thanks in advance. As regard to empty space leaping, I think your idea is good but usually out data (maily medical imaging data) have very few empty spaces so I would not pursue in that direction. Early ray termination uses different rendering order and that is really a problem. Do you think if it is possible to render the volume in the opposite direction so that the rendering order will be changed to front to back in volumizer? this needs to change modelviewproject matrix and manipulate the depth test. I have not thought carefully about this. and it can be too complicated in practice. -- Kevin On 11/8/05, Praveen Bhaniramka wrote: Kevin, I am not sure if you can change the interpolation filter in TMFragmentShader or not. You should try using the callbacks and see if they do the right thing for you. Another option would be to compute the "integral" texture coordinates in the fragment shader and then use them to sample the textures that you want to be NEAREST filtered. You can do somehting like - vec3 coordinates = volume_TexCoord * volume_TexDims; vec3 delta = fract(coordinates); vec3 integal = (coordinates - delta) / volume_TexDims; Yeah... I am sure that there are ways to improve the texture rendering using early ray termination and empty space leaping with Volumizer. You are right that 3D texture rendering is brute force in the sense that it slices the complete volume and renders the data. One easy way to implement empty space leaping is to compute a bounding geometry of the volume data that you know is visible and "cut-out", using geometry, the data that is not visible. Then use this bounding geometry for rendering the volume data set. That should improve the performance a bit. I am sure that early ray termination etc is also possible,.. I just haven't thought about that a lot. One potential issue there is that Volumizer currently does back-to-front rendering and early ray termination is typically useful for front-to-back rendering. Front-to-back rendering has other issues with embedded polygonal geometry in the same scene, etc. Let me know if you have other ideas or questions. - Praveen -----Original Message----- From: Kevin Wang [mailto: kwang22@gmail.com] Sent: Wednesday, November 09, 2005 3:11 AM To: praveenb@sgi.com Subject: Re: Cg support in OpenGL multipipe Hi Praveen, Thanks for your reply. I am using vzTMFragmentShader class, is it possible to change interpolation mode for it? Also I am thinking about ways to improve either quality or speed of volumizer. do you think it is possible to implement technique like early ray termination for volumizer so that only a fraction of the slices need to be rendered ( when the opacity reaches 1 then set Z buffer and using depth test to by pass rendering) ? As I understand, 3D texture mapping slices the volume and renders all the slices. Regards, -- Kevin On 11/5/05, Praveen Bhaniramka wrote: Hi Kevin, Currently, it is not possible to change the interpolation mode in Volumizer for the built-in shaders (LUT, Gradient, Tag, etc). The interpolation mode is set to be GL_LINEAR for all vzParameterVolumeTexture's and GL_NEAREST for all vzParameterLookupTable's used in the shader. However, if you are using vzTMFragmentProgram shader, Volumizer provides you callbacks for binding your various textures. In those callbacks, after you bind the volume texture (by using the bindVolumeTextureCB function), you set the interpolation modes using the glTexParameteri() commands. - Praveen -----Original Message----- From: Kevin Wang [mailto: kwang22@gmail.com] Sent: Saturday, November 05, 2005 1:51 AM To: praveenb@sgi.com Subject: Re: Cg support in OpenGL multipipe Praveen, Sorry I did not mean to use Cg compiler. I mean similarly it would apply to a GLSL compiler. anyway, it is not urgent now. I have got a new question for you now. I know volumizer uses 3D texture mapping technique. and when using it, usually we need to specify the interpolation mode during the texture setup. I wonder if there is a way i can change this mode during rendering with Volumizer? below is the OpenGL code to set up the interpolation mode. I want to use nearest neighbor mode in certain situations. glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_3D_EXT, GL_TEXTURE_MAX_FILTER, GL_LINEAR); Look forward to your response. Thanks. -- Kevin On 11/4/05, Praveen Bhaniramka > wrote: I am not sure if Cg compiler provides the option of converting GLSL to ARB_fragment_program. - Praveen -----Original Message----- From: Kevin Wang [mailto: kwang22@gmail.com] Sent: Friday, November 04, 2005 8:41 PM To: praveenb@sgi.com Subject: Re: Cg support in OpenGL multipipe Hi Praveen, Thanks for your response. Yes, I am using Propack 3 and we dont anticipate a system upgrade within the next half year. since the code is still in development stage, i guess we can wait for a while for the upgrade. Interesting that Cg program can be convert into a ARB_Fragment_program. then I would assume that so does GLSL program. I will look into that matter. Regards, -- Kevin On 11/4/05, Praveen Bhaniramka wrote: Hi Kevin, I am pretty sure that OpenGL Multipipe does not support Cg. The simple reason is that Prism does not support Cg and OpenGL Multipipe can only run on Prism! Actually, I got the following response from Guy, who is the tech lead on OMP. "OMP will support GLSL only with Propack 4 SP3. About performance improvement with OMP, if the app is fill limited (as I assume it should be) then OMP should scale the perfirmance." I would imagine that your Prism is currently running ProPack 3.x. So in order to use GLSL, you would need to use PP4 SP3 (which will be available in December AFAIK). For now, your best bet is to use ARB_fragment_program in Volumizer. You can still use Cg by running the Cg compiler and passing it your Cg program and asking it to convert the Cg program to ARB_fragment_program. You can then pass the fragment program to Volumizer directly. (Sorry for the delay in replying... I was travelling last week and earlier this week) hth, Praveen -----Original Message----- From: Kevin Wang [mailto:kwang22@gmail.com] Sent: Monday, October 24, 2005 9:57 PM To: Saurabh Gupta; Praveen Bhaniramka Subject: Cg support in OpenGL multipipe Importance: Low Hi Saurabh and Praveen, Do you guys know that if OpenGL multipipe supports Cg shading language? We have a custom developed raycasting volume rendering software package which uses opengl shading language. Praveen said that OMP doesnot support OpenGL shading language so I was wondering if it supports Cg or other high level shading language. and if possible, will the next release support OpenGL shading language? Regards, -- Kevin ------=_NextPart_000_000E_01C5EA60.A1530620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Kevin,
 
It is = strange=20 that the GLSL shader gives you linear interpolation even after = rounding the=20 texture coordinates to the nearest neighbour texel's coordinates. I = guess, you=20 might need to do some more debugging to make sure that the texture = coordinates=20 are being computed correctly. One simple way is to output the texture=20 coordinates to the screen and see if they look like they are nearest = neighbour=20 or linear interpolated.
 
Yeah... I did a=20 quick check as well and it does not look like we provide any way to = specify GL=20 texture parameter settings when using TMFragmentShader=20 class.
 
-=20 Praveen
-----Original Message-----
From:=20 owner-info-volumizer@els.sgi.com = [mailto:owner-info-volumizer@els.sgi.com]=20 On Behalf Of Kevin Wang
Sent: Tuesday, November 15, = 2005=20 10:49 PM
To: info-volumizer@els.sgi.com
Subject: = Re:=20 [info-volumizer] Re: GLSL Shader in Volumizer

Hi=20 Praveen,

I tried your code, still gives me linear interpolation = effect.=20 Also you have mentioned that using vzTMFragmentProgram I can set = callbacks and=20 change the interpolation mode there. but you are not sure about=20 vzTMFragmentShader. I checked sgi documentation. It seems there is no = way to=20 set callback for vzTMFragmentShader. Just want to let you know=20 that.

Regards,

-- Kevin

On 11/10/05, Praveen=20 Bhaniramka <praveenb@sgi.com>=20 wrote:
I=20 wonder what could be wrong with the GLSL shader. It seems = pretty
simple.=20 Can you try using vector operations instead of scalar ones = that
you are=20 using right now? So, your shader might look like -

"vec3 = coordinates,=20 delta, integal;\n"
"coordinates =3D vec3(volume_TexCoord) *=20 volume_TexDims;\n"
"delta =3D floor(coordinates);\n"
"integal = =3D (delta)=20 / volume_TexDims;\n"
"color =3D texture3D(volume,integal.stp);\n" =

This should also be more efficient and hopefully less liable = to=20 shader
compilation issues in the drivers.

No, we haven't=20 implemented GPU-based ray casting in Volumizer yet. There
are = issues with=20 the technique which might not allow it to work in real =
applications,=20 e.g. mixing polygonal geometry with the rendering, etc. It
is = definitely=20 something that we are thinking of doing in the future, but
so = far, GPU=20 ray casting is a good research prototype=20 IMHO.

Cheers,
Praveen

-----Original = Message-----
From:=20 owner-info-volumizer@els= .sgi.com
[mailto:owner-info-volumizer@els= .sgi.com=20 ] On Behalf Of Kevin Wang
Sent: Thursday, November 10, 2005 = 8:56=20 PM
To: praveenb@sgi.com; = info-volumizer@els.sgi.com=
Subject:=20 [info-volumizer] Re: Cg support in OpenGL multipipe =


Hi,

I=20 did not get any compilation errors. I set $VOLUMIZER_DEBUG_LEVEL to = 5
to=20 see all the debug info and I can see nothing wrong.

Well, = maybe early=20 ray termination is not a good idea for 3D texture
mapping. Do = you guys=20 have a plan to implement GPU based ray casting = in
Volumizer?

--=20 Kevin


On 11/10/05, Praveen Bhaniramka <praveenb@sgi.com> = wrote:
Not sure=20 what is going on. Do you get any errors from Volumizer about
the = shader=20 compilation? If the shader does not compile, Volumizer will
give = you an=20 error.

Volumizer will always use back-to-front slicing based = on the=20 transform
matrices set by the application. So, mucking with the = matrices=20 might not
really help. I will try and think about some other = solution for=20 you as
well.

- Praveen
-----Original = Message-----
From:=20 Kevin Wang [mailto: kwang22@gmail.com]

Sent:=20 Thursday, November 10, 2005 1:17 AM
To: praveenb@sgi.com
Subject: = Re: Cg=20 support in OpenGL multipipe


Hi Praveen,

Thanks for = your=20 ideas.

I have tried your second recommendation regarding=20 interpolation mode
using the following GLSL program.

"vec3 = coordinates, delta, integal;\n"
" coordinates.s =3D = volume_TexCoord.s *=20 volume_TexDims.x;\n"
"coordinates.t =3D volume_TexCoord.t *=20 volume_TexDims.y;\n"
"coordinates.p =3D volume_TexCoord.p *=20 volume_TexDims.z;\n"
"delta.s =3D floor( = coordinates.s);\n"
"delta.t =3D=20 floor(coordinates.t);\n"
"delta.p =3D=20 floor(coordinates.p);\n"
"integal.s =3D (delta.s ) /=20 volume_TexDims.x;\n"
"integal.t =3D (delta.t ) / = volume_TexDims.y;\n"=20
"integal.p =3D (delta.p ) / volume_TexDims.z;\n"
"color =3D=20 texture3D(volume,integal.stp);\n"

Originally the code = is
"color =3D=20 texture3D(volume,volume_TexCoord.stp);\n"

Now the problem is = that=20 nothing shows up in my program. Since I am new
to GLSL so I = wonder if=20 you can test this code for me. Thanks in advance.

As regard = to empty=20 space leaping, I think your idea is good but usually
out data = (maily=20 medical imaging data) have very few empty spaces so I
would not = pursue=20 in that direction. Early ray termination uses different
rendering = order=20 and that is really a problem. Do you think if it is
possible to = render=20 the volume in the opposite direction so that the
rendering order = will be=20 changed to front to back in volumizer? this
needs to change=20 modelviewproject matrix and manipulate the depth test. I
have not = thought=20 carefully about this. and it can be too complicated=20 in
practice.

-- Kevin




On 11/8/05, = Praveen=20 Bhaniramka <praveenb@sgi.com>=20 wrote:
Kevin,

I am not sure if you can change the = interpolation=20 filter in
TMFragmentShader or not. You should try using the = callbacks=20 and see if
they do the right thing for you. Another option would = be to=20 compute the
"integral" texture coordinates in the fragment shader = and=20 then use them
to sample the textures that you want to be NEAREST = filtered. You can do
somehting like = -
    vec3=20 coordinates =3D volume_TexCoord *=20 volume_TexDims;
    vec3 delta =3D=20 fract(coordinates);
    vec3 integal =3D = (coordinates -=20 delta) / volume_TexDims;

Yeah... I am sure that there are = ways to=20 improve the texture rendering
using early ray termination and = empty space=20 leaping with Volumizer. You
are right that 3D texture rendering = is brute=20 force in the sense that it
slices the complete volume and = renders the=20 data. One easy way to
implement empty space leaping is to compute = a=20 bounding geometry of the
volume data that you know is visible and = "cut-out", using geometry,  the
data that is not = visible. Then=20 use this bounding geometry for rendering
the volume data set. = That should=20 improve the performance a bit. I am
sure that early ray = termination etc=20 is also possible,.. I just haven't
thought about that a lot. One = potential issue there is that Volumizer
currently does = back-to-front=20 rendering and early ray termination is
typically useful for = front-to-back=20 rendering. Front-to-back rendering
has other issues with embedded = polygonal geometry in the same scene,
etc.

Let me know if = you have=20 other ideas or questions.

- Praveen

-----Original=20 Message-----
From: Kevin Wang [mailto: kwang22@gmail.com]

Sent:=20 Wednesday, November 09, 2005 3:11 AM
To: praveenb@sgi.com
Subject: = Re: Cg=20 support in OpenGL multipipe


Hi Praveen,

Thanks for = your=20 reply. I am using vzTMFragmentShader class, is it
possible to = change=20 interpolation mode for it?

Also I am thinking about ways to = improve=20 either quality or speed of
volumizer. do you think it is possible = to=20 implement technique like early
ray termination for volumizer so = that only=20 a fraction of the slices need
to be rendered ( when the opacity = reaches=20 1 then set Z buffer and using
depth test to by pass rendering) ? = As I=20 understand, 3D texture mapping
slices the volume and renders all = the=20 slices.

Regards,

-- Kevin


On 11/5/05, = Praveen=20 Bhaniramka <praveenb@sgi.com>=20 wrote:
Hi Kevin,

Currently, it is not possible to change = the=20 interpolation mode in
Volumizer for the built-in shaders (LUT, = Gradient,=20 Tag, etc). The
interpolation mode is set to be GL_LINEAR for=20 all
vzParameterVolumeTexture's and GL_NEAREST for=20 all
vzParameterLookupTable's used in the shader.

However, = if you=20 are using vzTMFragmentProgram shader, Volumizer provides
you = callbacks=20 for binding your various textures. In those callbacks,
after you = bind the=20 volume texture (by using the bindVolumeTextureCB
function), you = set the=20 interpolation modes using the = glTexParameteri()
commands.

-=20 Praveen

-----Original Message-----
From: Kevin Wang = [mailto: kwang22@gmail.com]

Sent:=20 Saturday, November 05, 2005 1:51 AM
To: praveenb@sgi.com
Subject: = Re: Cg=20 support in OpenGL multipipe


Praveen,

Sorry I did = not mean=20 to use Cg compiler. I mean similarly it would apply
to a GLSL = compiler.=20 anyway, it is not urgent now.

I have got a new question for = you now.=20 I know volumizer uses 3D texture
mapping technique. and when = using it,=20 usually we need to specify the
interpolation mode during the = texture=20 setup. I wonder if there is a way
i can change this mode during=20 rendering with Volumizer? below is the
OpenGL code to set up the=20 interpolation mode. I want to use nearest
neighbor mode in = certain=20 situations.

glTexParameteri(GL_TEXTURE_3D_EXT, = GL_TEXTURE_MIN_FILTER,=20 GL_LINEAR);
glTexParameteri(GL_TEXTURE_3D_EXT, = GL_TEXTURE_MAX_FILTER,=20 GL_LINEAR);

Look forward to your response. Thanks.

--=20 Kevin


On 11/4/05, Praveen Bhaniramka <praveenb@sgi.com > = wrote:
I am not=20 sure if Cg compiler provides the option of converting GLSL=20 to
ARB_fragment_program.

- Praveen
-----Original=20 Message-----
From: Kevin Wang [mailto: kwang22@gmail.com]

Sent: = Friday,=20 November 04, 2005 8:41 PM
To: praveenb@sgi.com
Subject: = Re: Cg=20 support in OpenGL multipipe


Hi Praveen,

Thanks for = your=20 response. Yes, I am using Propack 3 and we dont
anticipate a = system=20 upgrade within the next half year. since the code is
still in = development=20 stage, i guess we can wait for a while for=20 the
upgrade.

Interesting that Cg program can be convert = into a=20 ARB_Fragment_program.
then I would assume that so does GLSL = program. I=20 will look into that
matter.

Regards,

-- = Kevin


On=20 11/4/05, Praveen Bhaniramka <praveenb@sgi.com > wrote: =
Hi=20 Kevin,

I am pretty sure that OpenGL Multipipe does not = support Cg.=20 The simple
reason is that Prism does not support Cg and OpenGL = Multipipe=20 can only
run on Prism! Actually, I got the following response = from Guy,=20 who is
the tech lead on OMP.

"OMP will support GLSL only = with=20 Propack 4 SP3. About performance
improvement with OMP, if the app = is fill=20 limited (as I assume it should
be) then OMP should scale the=20 perfirmance."

I would imagine that your Prism is currently = running=20 ProPack 3.x. So in
order to use GLSL, you would need to use PP4 = SP3=20 (which will be
available in December AFAIK). For now, your best = bet is to=20 use
ARB_fragment_program in Volumizer. You can still use Cg by = running=20 the
Cg compiler and passing it your Cg program and asking it to = convert=20 the
Cg program to ARB_fragment_program. You can then pass the=20 fragment
program to Volumizer directly.

(Sorry for the = delay in=20 replying... I was travelling last week and
earlier this=20 week)

hth,
Praveen

-----Original = Message-----
From:=20 Kevin Wang [mailto:kwang22@gmail.com]
Sent: = Monday,=20 October 24, 2005 9:57 PM
To: Saurabh Gupta; Praveen Bhaniramka=20
Subject: Cg support in OpenGL multipipe
Importance: = Low


Hi=20 Saurabh and Praveen,

Do you guys know that if OpenGL = multipipe=20 supports Cg shading language?
We have a custom developed = raycasting=20 volume rendering software package
which uses opengl shading = language.=20 Praveen said that OMP doesnot
support OpenGL shading language so = I was=20 wondering if it supports Cg or
other high level shading language. = and if=20 possible, will the next
release support OpenGL shading language?=20

Regards,

--=20 Kevin


------=_NextPart_000_000E_01C5EA60.A1530620-- From info-volumizer-owner@els.sgi.com Wed Nov 16 07:36:37 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jAGFZdQ39067117; Wed, 16 Nov 2005 07:35:39 -0800 (PST) Received: from surfboard.ka.sara.nl (surfboard.ka.sara.nl [145.100.6.3]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jAG8t5JT9056007 for ; Wed, 16 Nov 2005 00:55:06 -0800 (PST) Received: from [145.100.25.205] ([145.100.25.205] RDNS failed) by surfboard.ka.sara.nl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 09:55:01 +0100 Message-ID: <437AF3EF.1030109@sara.nl> Date: Wed, 16 Nov 2005 09:55:11 +0100 From: Jeroen Akershoek Organization: SARA User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: info-volumizer@els.sgi.com Subject: [info-volumizer] Overlapping volumes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 08:55:01.0997 (UTC) FILETIME=[6E30C1D0:01C5EA8B] Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com Hello, I've got the following situation: Got two volumes, both same dimensions and formats and such. Basically I want to do the following: if (A>0.3 && B < 0.3) use(LUT0) if (A<0.3 && B > 0.3) use (LUT1) if (A>0.3 && B > 0.3) use (LUT2) if (A<0.3 && B < 0.3) KIL I tried doing something similar with a FragmentProgram shader, but since that doesn't have conditionals, it's not all too easy. I took a peak at ISL (due to lack of OGL2 and thus GLSL on Onyx4), which should be able to do it, but the ISLLoader crashes the program. par trace shows that it's doing a lot of brk() calls and then the program terminates in "illegal instruction". I know ISL is deprecated, not supported and everything, but it should still work, right? Any ideas on how to do this are welcome, either ARBfp, ISL or other OpenGL (Up to 1.4 sadly enough) code Kind regards, Jeroen -- Jeroen Akershoek SARA Computing and Network Services - Visualisation department tel: +31 20 5923000 fax: +31 20 6683167 Draco dormiens nunquam titillandus From info-volumizer-owner@els.sgi.com Wed Nov 16 07:36:37 2005 Received: (from majordom@localhost) by els.sgi.com (8.12.10/8.12.2/els-2.2) id jAGFZdwb8904440; Wed, 16 Nov 2005 07:35:39 -0800 (PST) Received: from styks.polsl.pl (styks.polsl.pl [157.158.3.13]) by els.sgi.com (8.12.10/8.12.2/els-2.2) with ESMTP id jAG8f0JT9049793 for ; Wed, 16 Nov 2005 00:41:01 -0800 (PST) Received: from 157.158.17.23 ([157.158.17.23]) by styks.polsl.pl ([157.158.3.13]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Nov 2005 08:40:56 +0000 MIME-Version: 1.0 content-class: urn:content-classes:message From: Dominik Spinczyk Content-Type: multipart/alternative; boundary="_1F63F781-FEC3-4185-A2A0-260DD2E5936A_" Subject: [info-volumizer] OpenGL Voluzmizer 2.9 on WinXP - problem with licence fike To: "info-volumizer@els.sgi.com" Thread-Topic: OpenGL Voluzmizer 2.9 on WinXP - problem with licence fike Thread-Index: AcXqiXiNdNr/yJzAQ2a6jJMCe+CdHQ== Message-ID: <5B812C67-491A-4F7B-A8F2-1121067FED38@mimectl> X-Mailer: Microsoft Outlook Web Access 6.5.7233.28 X-MimeCtl: Produced By Microsoft Exchange V6.5.7233.28 Date: Wed, 16 Nov 2005 09:41:00 +0100 Sender: owner-info-volumizer@els.sgi.com Precedence: bulk Reply-To: info-volumizer@els.sgi.com --_1F63F781-FEC3-4185-A2A0-260DD2E5936A_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable =20 Would You give me a little help ? I can't run demo applications=20 I installed: OpenGL Volumizer to directory: e:\win32app\Silicon Graphics\O= penGL Volumizer and TIFFforWIndows to e:\win32app\GnuWin32 I copied files form GLUT for Windows to destionation path. = =20 I compild all sourcess ( buildall using Visual C++ 6 ). I prepared license.dat file and copied it to e:\win32app\Silicon Graphics\O= penGL Volumizer =20 =20 I set following System Variable : VOLUMIZER_DEBUG_LEVEL 4 LM_LICENSE_FILE e:\win32app\Silicon Graphics\OpenGL Volumizer\licen= se.dat VZROOT e:\win32app\Silicon Grphics\OpenGl Volumizer VTKPATH c:\Program Files\vtk42 TIFFPATH e:\win32app\GnuWin32 PATH e:\win32app\Silicon Grahics\OpenGL Voluzmier\bin I use Radeon 9700 graphic card. I can't run Sample Applicaations. What I do wrong ? This is a screen shoot of runsimple.bat --------------------------------------------- Running all Volumizer sample applications --------------------------------------------- ------------------------------------------------------------ Running example program (pguide) in the Volumizer Manual ------------------------------------------------------------ TIFFPATH is set to e:\win32app\GnuWin32 Initializing debug Level to: 4 Volumizer (3): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Volumizer (3): Checking for 'volumizer_windows' license Volumizer Warning: 'volumizer_windows' License check failed. Reason: Volumizer (0): Exact Error Message from License Manager is: Volumizer (0): --> No SERVER lines in license file Feature: volumizer_windows License path: e:\win32app\Silicin Graphics\OpenGL Volumizer\license.dat; C:\flexlm\license.dat;e:\win32app\Silicon Graphics\OpenGL Volumizer - \*.lic;e:\win32app\Silicon Graphics\OpenGL Volumizer\license.dat FLEXlm error: -13,128. System Error: 2 "" For further information, refer to the FLEXlm End User Manual, available at "https://poczta.polsl.pl/exchweb/bin/redir.asp?URL=3Dhttp://ww= w.globetrotter.com/". Volum