I just checked the adobe forums, appears it's not working. XP don't run it at all and another complaining it doesn't run on a mac. I think we might have to wait a while for this.
D On 22 March 2011 08:04, Michael Iv <[email protected]> wrote: > Yeah Darcey ,that is what I think too.But the problem is that the util > console doesn't open.I mean it opens ,write some error and shuts down > immediately . > > > On Tue, Mar 22, 2011 at 10:01 AM, Darcey Lloyd <[email protected]>wrote: > >> Looks like you compile with "pb3dutil.exe" I've not tried compiling >> anything with it yet though. >> >> Params from dos: >> pb3dutil [input vertex lernel file name] [output file name] [input >> material kernel file name] [material vertex output file name] >> >> I'm guessing write your stuff up in an editor of your choice and compile >> via dos. Possible suggestion when molehill and pb3d is released Away 4.x can >> have a selection of pb3d extensions which we can include when needed. or >> something along those lines. >> >> D >> >> >> >> On 22 March 2011 07:13, Michael Iv <[email protected]> wrote: >> >>> In fact ,if you guys are familiar with the new OpenGL 3x (non fixed ) >>> pipeline which is solely based on shader programming ,you will find it very >>> much similar to how Molehill works.Of course you are right saying that the >>> Molehill doesn't have all the OpenGL functionality (it hardly has a fracture >>> of it).But because you have got the ability to manipulate buffers data and >>> draw the stuff based on frag/vertex programs it means you can do pretty >>> everything you can dream of.The only real impediment is all those nasty >>> opcodes(unlike GLSL ) .But I personally believe that PixelBender3D will come >>> to rescue in this case. >>> >>> BTW anybody succeeded to compile anything with the beta release of PB3D? >>> I downloaded the pack.There is a command line exe in there with several DLLs >>> and no proper docs what to do with it except of compile commands.Are we >>> supposed to write the program in PB2.5 IDE and then compile with the command >>> line Utility? >>> >>> >>> On Tue, Mar 22, 2011 at 1:21 AM, Brian Bosak < >>> [email protected]> wrote: >>> >>>> Or you could write a virtual OpenGL wrapper for Molehill. Wouldn't be >>>> too difficult actually. >>>> >>>> -----Original Message----- From: Arkadianen >>>> Sent: Monday, March 21, 2011 6:05 PM >>>> >>>> To: Away3D.dev >>>> Subject: [away3d] Re: Away3D 4.x - GPU Access >>>> >>>> Flash doesnt have the purpose to transit OpenGL functions. But if you >>>> need some specific functions you can discuss them with Adobe team. >>>> YOu can create a separated topic and in future releases they will be >>>> implemented. >>>> >>>> On Mar 20, 5:47 pm, "Brian Bosak" <[email protected]> wrote: >>>> >>>>> Yeah. Currently Molehill doesn't support all of the functionality I was >>>>> expecting, so I'm transitioning my project over to native OpenGL. Flash >>>>> just >>>>> isn't quite ready yet, and there's no standard way to even capture the >>>>> mouse >>>>> cursor, or set the screen resolution. >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Arkadianen >>>>> Sent: Sunday, March 20, 2011 10:18 AM >>>>> To: Away3D.dev >>>>> Subject: [away3d] Re: Away3D 4.x - GPU Access >>>>> >>>>> So latest GPU cards supports even C++ >>>>> But we cant use all of its possibilities in Flash, we can use only >>>>> methods of ActionScript which use GPU. >>>>> I think in future Flash will evolve to larger use of GPU >>>>> >>>>> On Mar 20, 1:05 am, Michael Iv <[email protected]> wrote: >>>>> > And here is more detailed info: >>>>> >>>>> >http://www.nvidia.com/object/GPU_Computing.html >>>>> >>>>> > On Sun, Mar 20, 2011 at 12:39 AM, Michael Iv <[email protected]> >>>>> > wrote: >>>>> > > This is faster due to the fact the modern graphic(dedicated) cards >>>>> > > have >>>>> > > hundreds of GPUs executing in parallel .The only issue is the bus >>>>> > > between >>>>> > > CPU and GPU. the transition of the data to the card and from it is >>>>> > > what >>>>> > > usually prevents to get the best out of this approach.But still I >>>>> > > believe if >>>>> > > you architecture the CPU (client side) code the right way you will >>>>> > > gain >>>>> > > much >>>>> > > from it.I did not try it.I am learning PB3D now because I am not >>>>> going >>>>> > > to >>>>> > > suffer doing such a stuff with opcodes.As I wrote today earlier > >>>>> > "number >>>>> > > crunching "(term to what you want to do ) was already done in PB2d >>>>> > > .There is >>>>> > > an article on Adobe PixelBender page describing how to send > > >>>>> computations >>>>> > > to >>>>> > > PixelBender and back.Read it,I think it will be helpful .:) >>>>> >>>>> > > On Sun, Mar 20, 2011 at 12:28 AM, Arkadianen <[email protected] >>>>> > >>>>> > > wrote: >>>>> >>>>> > >> This matter is very importnat, because collision detection takes >>>>> lots >>>>> > >> of CPU. Is GPU able to calculate it faster than CPU? Maybe we >>>>> could >>>>> > >> even write shaders for path finding or other games tasks like AI ? >>>>> > >> Did anyone try it? >>>>> > >> Having links? >>>>> >>>>> > >> On Mar 19, 11:11 am, Michael Iv <[email protected]> wrote: >>>>> > >> > I am still learning the API but here are some things I can tell >>>>> you > >> > : >>>>> > >> > Yes you can send the data to the gpu to be calculated . For this >>>>> > >> > you >>>>> > >> should write a shader program which would get input of soma data >>>>> and >>>>> > >> return >>>>> > >> the calculated result . I think the best way to do that is via >>>>> pb3d > >> so >>>>> > >> you >>>>> > >> don't have to mess around with opcodes. Also this thing was >>>>> already >>>>> > >> done >>>>> > >> with the regular pixel bender. There is an article in pb adobe web >>>>> > >> page >>>>> > >> about number crunching using pb shaders. Just take a look at it >>>>> .btw > >> , >>>>> > >> the >>>>> > >> industry standard physics engines like PhysX and Havok run on GPU >>>>> :) >>>>> >>>>> > >> > Sent from my iPhone >>>>> >>>>> > >> > On Mar 19, 2011, at 1:34 AM, Darcey Lloyd < >>>>> [email protected]> >>>>> > >> wrote: >>>>> >>>>> > >> > > I have just been wandering through some gpu collision >>>>> detection >>>>> > >> articles and was wondering: >>>>> >>>>> > >> > > Q1). Is there any way to access the GPU for collision >>>>> detection >>>>> > >> queries, freeing the CPU from testing? Or when we do a comparison >>>>> > >> between >>>>> > >> two vertices does molehill automatically get the GPU to do this? >>>>> Is >>>>> > >> this >>>>> > >> possible via stage3D / Context3D? >>>>> >>>>> > >> > > Q2). How much access do we have to the GPU? >>>>> >>>>> > >> > > Q3). Would it be possible to have more access to GPU > >> > > >>>>> functionality >>>>> > >> > > via >>>>> > >> pbj objects (Pixelbender)? >>>>> >>>>> > >> > > D >>>>> >>>>> > > -- >>>>> > > Michael Ivanov ,Programmer >>>>> > > Neurotech Solutions Ltd. >>>>> > > Flex|Air |3D|Unity| >>>>> > >www.neurotechresearch.com >>>>> > >http://blog.alladvanced.net >>>>> > > Tel:054-4962254 >>>>> > > [email protected] >>>>> > > [email protected] >>>>> >>>>> > -- >>>>> > Michael Ivanov ,Programmer >>>>> > Neurotech Solutions Ltd. >>>>> > Flex|Air |3D|Unity|www.neurotechresearch.comhttp:// >>>>> blog.alladvanced.net >>>>> > Tel:054-4962254 >>>>> > [email protected] >>>>> > [email protected] >>>>> >>>> >>>> >>> >>> >>> -- >>> Michael Ivanov ,Programmer >>> Neurotech Solutions Ltd. >>> Flex|Air |3D|Unity| >>> www.neurotechresearch.com >>> http://blog.alladvanced.net >>> Tel:054-4962254 >>> [email protected] >>> [email protected] >>> >>> >> > > > -- > Michael Ivanov ,Programmer > Neurotech Solutions Ltd. > Flex|Air |3D|Unity| > www.neurotechresearch.com > http://blog.alladvanced.net > Tel:054-4962254 > [email protected] > [email protected] > >
