Tore Posted January 23, 2016 Share Posted January 23, 2016 (edited) - Edited April 19, 2018 by Tore Quote Link to comment Share on other sites More sharing options...
Hash Fellow robcat2075 Posted January 23, 2016 Hash Fellow Share Posted January 23, 2016 Steffen gave OpenCL (the open source version of GPU computing) rendering a big try when he was developing v18 but it did not have the reliability or the increased speed that was hoped for.Hash had a similar experience when they tried to implement Gelato (Nvidia's original GPU rendering scheme) some 10 years ago.For now, the idea is on hold until some substantial improvements in the development tools arrive. Quote Link to comment Share on other sites More sharing options...
Tore Posted January 23, 2016 Author Share Posted January 23, 2016 (edited) - Edited April 19, 2018 by Tore Quote Link to comment Share on other sites More sharing options...
Tore Posted January 23, 2016 Author Share Posted January 23, 2016 (edited) - Edited April 19, 2018 by Tore Quote Link to comment Share on other sites More sharing options...
Hash Fellow robcat2075 Posted January 23, 2016 Hash Fellow Share Posted January 23, 2016 CUDA is an NVidia proprietary way doing pretty much the same stuff as OpenCL As far as I know it is not different enough to expect the results would be much different. from Wikipedia: Unlike OpenCL, CUDA-enabled GPUs are only available from Nvidia[17] OpenCl supports both NVidia and AMD GPUs so that was the choice to try on A:M because A:M needs to support both. I don't know a lot about this area of computing and my explanations will be very basic and probably inaccurate but that doesn't mean that Steffen overlooked some simple thing that everyone else in the world knows. Steffen really did put a lot of time into implementing it and trying it, but just as the Hash programmers found out with Gelato, the things that A:M does don't seem to benefit much from this sort of GPU computing. It is not going to be a simple matter of using CUDA instead of OpenCL. There is really nothing more that I can explain about it. Steffen would have to weigh in to give more insight. Quote Link to comment Share on other sites More sharing options...
John Bigboote Posted January 24, 2016 Share Posted January 24, 2016 I've had some success modelling and animating in AM and exporting obj sequences to Element 3D which lives within After Effects... E3D is a gpu processor... very swift, great effects like SSS and DOF... works great for motion graphics, not so much for character stuff. Quote Link to comment Share on other sites More sharing options...
Hash Fellow robcat2075 Posted January 24, 2016 Hash Fellow Share Posted January 24, 2016 E3D is a gpu processor... very swift, great effects like SSS and DOF... works great for motion graphics, not so much for character stuff. What is the drawback for character work? Quote Link to comment Share on other sites More sharing options...
detbear Posted January 26, 2016 Share Posted January 26, 2016 This is why A:M really should revisit it's export of mesh animations(and exports in general) and test them in various engines to improve the transfers. It seems as though no real-time solutions are going to be available in A:M anytime soon. BUT I do think the exporter quality and variety could be improved for faster and more use able mesh animation exports. Just my opinion, but this would patch the gap until real time rendering solutions could be achieved in A:M. Imagine if A:M had a special export to AE specifically streamlined for use in Element. Or a dedicated system to export FBX without having to fight through the current workarounds. Quote Link to comment Share on other sites More sharing options...
Admin Rodney Posted January 26, 2016 Admin Share Posted January 26, 2016 Imagine Much easier to imagine than implement. A:M really should revisit it's export of mesh animations(and exports in general) Export gets revisited from time to time but exporters are usually plugins. These usually require external development. Someone with the need usually develops the solution. An example of this is Arthur Waselec (and others) who have coded exporters. At one time Arthur offered to assist others with updating his plugins. I'm not sure if the offer still stands or if anyone took him up on the offer. and test them in various engines to improve the transfers. Testing takes additional time... has to be factored into development. It seems as though no real-time solutions are going to be available in A:M anytime soon. It's hard to predict the future. Just when we think we see it clearly... off in some other direction it goes. exporter quality and variety could be improved for faster and more use able mesh animation exports. Yes, quality and variety can always be improved. Just my opinion No not just opinion. Thus far I believe you have posted facts and expressed your desires. (improved exporters) would patch the gap until real time rendering solutions could be achieved in A:M. It seems to me that we need experts who work with those other programs to gravitate toward developing plugins for A:M. It's harder for folks who don't have the need, access, interest, etc. to break through that gap. I'd say it's like someone breaking through a wall that requires 20% effort versus someone on the other side who would require 80% (or simply lacks the manpower or tool). The ideal solution would appear to be that of pairing someone with the knowledge from both sides of the wall and have them communicate and explore optimal solutions to breaking through. Offers have been made in the past but usually interest fades quickly as soon as the idea meets up with real world resistance of almost any magnitude. Imagine if A:M had I spend an inordinate amount of time imagining things that A:M can have. if A:M had a special export to AE specifically streamlined for use in Element. Or a dedicated system to export FBX without having to fight through the current workarounds. How much would that be worth to us? I'd be more than willing to pay another $20 a year... bumping A:M's annual price back to $99 a year but I can't speak for others. For many/most, $79 a year is too much. And I recognize that $20 is not enough to fund development of even one of these exporters. I'm not sure what the solution is. Perhaps we can run a campaign, "Show some love for A:M" and see how many folks will subscribe for a year to send a loud and clear message that we all want to see A:M step up the pace in development and are willing to financially support that effort? Perhaps Jason could make sure the Hash Inc store won't refund additional funds paid at time of purchase and folks could pay more than the minimum amount? Or perhaps a second option to purchase A:M for $99 could be added to the store and folks could choose between the cheaper and more expensive to let Hash Inc know the development interest is for the future. Aside: I had best state why I talk about money here so that my intent doesn't get misconstrued. Moneys primary function in this capacity is to shorten the time of development. Without specific funds to pay a programmer to write code, new lines of code tend to flow at a slower, natural pace. When funds are set aside for specific purposes then those purposes can receive focused time and attention. Money isn't the full solution either however because of stipulations often attached to those funds. Example: I'd pay $200 more for A:M if it had . $200 more of imaginary funding will only buy me $200 more of imaginary development. There are logical steps we can take that meet with reality and yet drive solutions. One of the simplest steps is to add a Feature request into A:M Reports. But most of us (I'm talking mainly about me here) don't even get that far in our efforts to develop the future. There is an infinite amount of things that can be done to improve A:M. Special exporters require special attention and FBX exporters a knowledge of import/export solutions. -- a slight aside: Most folks desire exporters but fewer see with clarity that we need the full cyclic solution that includes the importer too. Perhaps when we say 'exporter' we actually see that as importer-inclusive. The code to produce each is considerably different so this shouldn't be the case but as end users we don't care about that stuff, we just want the immediate solution. We have several exporters whose created content is one-way only which is sub-optimal. In a perfect world any data that can be exported/saved out of A:M should be able to make the round trip back into A:M also. (But... dangerwillrobinson,.. full solutions tie up developers who cannot go on to explore other code). Some other practical steps we can take (especially in the interim) is to document current approaches and best practices with... I dare say... an A:M-centric approach. Many non-funded purchase orders start off with 'how can A:M help me use this other program'. And so the idea generally starts off broke and has to be resorted. In my day job (actually a night job) I often resort to a saying that generally states, "a great idea that cannot be implemented isn't a very practical solution'. Something that can help in this regard is to list constraints/obstacles that prove troublesome to those ideas. It may be that someone has already formulated a workaround or viable solution. Quote Link to comment Share on other sites More sharing options...
detbear Posted January 26, 2016 Share Posted January 26, 2016 Well said Rodney. All great points. I completely agree and understand the limitations of developing "new" features. Money and time are obstacles. Quote Link to comment Share on other sites More sharing options...
John Bigboote Posted January 26, 2016 Share Posted January 26, 2016 E3D is a gpu processor... very swift, great effects like SSS and DOF... works great for motion graphics, not so much for character stuff. What is the drawback for character work? Here is an example of how I am using A:M E3D... doing an awards show presentation graphics(yawn) and the award calls for a 'gold crown'... clients had nothing designed. I googled 'crown' and one of the 1st images was an ideal design. Using it as reference, in A:M I modelled it and exported as an obj. Import that into AE/E3D and apply a gold texture and adjust the physical attributes, lighting, AO etc. I am working at 1920 X1080 on a fast PC... not going to say it renders 'real-time' but it renders pretty durn close to real time... I just rendered a :10 test loop, it took :14 to render- and that is WITH all the extra compositing and glitzy layers and filters I added in AE... AS FAR AS CHARACTER stuff... I dunno- I guess I say that mostly because I have not tried it too much yet. There would be the issue of exporting the obj sequence... replacing all textures... I am spoiled by A:M, ever try to adjust lights or camera in AE??? It is a terrible, terrible interface. Maybe I'll give it a try again. Quote Link to comment Share on other sites More sharing options...
Tore Posted March 11, 2016 Author Share Posted March 11, 2016 (edited) - Edited April 19, 2018 by Tore Quote Link to comment Share on other sites More sharing options...
Fuchur Posted March 11, 2016 Share Posted March 11, 2016 Very interesting! See you *Fuchur* 1 Quote Link to comment Share on other sites More sharing options...
Willi Posted September 12, 2017 Share Posted September 12, 2017 what about cycles renderer. it is open source for a while now...maybe an implementation via the sdk is possible? or as standalone renderer with export plugins? Quote Link to comment Share on other sites More sharing options...
pixelplucker Posted November 13, 2017 Share Posted November 13, 2017 What about simply baking the lighting, textures and shadows on still objects in scenes then let AM be able to export that out as a seqence? This would be more like how a game engine would work and the calculations could be done one or at key frames or nth frames. Doable? Quote Link to comment Share on other sites More sharing options...
Hash Fellow robcat2075 Posted November 14, 2017 Hash Fellow Share Posted November 14, 2017 You can bake most textures. You can't bake lighting and shadows. But lighting and shadows is what the other renderer is for, right? Quote Link to comment Share on other sites More sharing options...
John Bigboote Posted November 14, 2017 Share Posted November 14, 2017 I've just noticed this for the 1st time... There is a GPU column in NetRender. I had opened some Render Messengers using my desktop link for V18 NR and saw the GPU tab was unchecked... when I updated my desktop link to the V19 RM all my Slaves are now GPU...? I don't really see any improved render times... this is new! Quote Link to comment Share on other sites More sharing options...
Hash Fellow robcat2075 Posted November 14, 2017 Hash Fellow Share Posted November 14, 2017 GPU in Netrender still only applies to things that A:M uses it for like SSAO. I suppose it's possible you might disable it to prevent a bottleneck of several frames trying to do SSAO at once or if there were some inconsistency in results among frames on different computers with different GPUs? Quote Link to comment Share on other sites More sharing options...
pixelplucker Posted November 14, 2017 Share Posted November 14, 2017 I forget the name of the game engine that AM had at one time. Wonder if that is a good route for this sort of thing? Quote Link to comment Share on other sites More sharing options...
Fuchur Posted November 15, 2017 Share Posted November 15, 2017 It was HA:MR if I am not wrong. But it was using OpenGL/Direct3d (as realtime in A:M itself). Best regards *Fuchur* Quote Link to comment Share on other sites More sharing options...
Elm Posted October 9, 2018 Share Posted October 9, 2018 Hi! Any news on this? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.