What will be timeframe for that to be available inside XSI?they are working in the new gi now, its on top of their list, so you have to wait a bit more.
How rendering should be
Re: How rendering should be
- H -
Re: How rendering should be
5 years probably, since we are still waiting for progressive rendering to be implemented and many other things. Cant blame mental images for anything when it comes to implementation, AD is just crap into implementing things and feature wise. So yeah, considering AD background dont expect to see it anytime soon, and even when this new features will come out, dont expect to see them in Xsi, they'll prolly go to Maya or Max first.SreckoM wrote:What will be timeframe for that to be available inside XSI?they are working in the new gi now, its on top of their list, so you have to wait a bit more.
Years i'd say.
Re: How rendering should be
there is no timeframe at the moment. but, and i think you mean this, as soon as mi implement this and ad NOT, it will be very funny to see whats happen. ;)SreckoM wrote:What will be timeframe for that to be available inside XSI?they are working in the new gi now, its on top of their list, so you have to wait a bit more.
Re: How rendering should be
dont know how long it will take to get string options in xsi, max will get it soon, maya has it already. so its not a problem to implement this in maya, i am pretty sure it will be a custom ui for this. and people like thorsten will work on a implementation in max because he will use it. xsi implementation depends to much on ad at the moment, i hope this will change soon enough.Maximus wrote:5 years probably, since we are still waiting for progressive rendering to be implemented and many other things. Cant blame mental images for anything when it comes to implementation, AD is just crap into implementing things and feature wise. So yeah, considering AD background dont expect to see it anytime soon, and even when this new features will come out, dont expect to see them in Xsi, they'll prolly go to Maya or Max first.SreckoM wrote:What will be timeframe for that to be available inside XSI?they are working in the new gi now, its on top of their list, so you have to wait a bit more.
Years i'd say.
Re: How rendering should be
I recently tried Blender briefly along with Cycles and I now feel we're in the stone age with rendering in SI. I dread learning yet another major ap but it sure seems tempting so far.
I imported a large .obj file and it loaded in about 1/2 a second (SI took over a minute). The viewport seemed at least as fast as SI and rendering was a joy. I will be investigating further, but it's pretty impressive. They're gaining ground fast.
What disappoints me most is SI could have easily had something similar with Iray but instead wasted their time with this wretched HQVP. I've tried many times to use it but it's utterly useless. The scene translation or whatever it's called is so slow it's laughable. It would have to be 50x faster to be any use at all.
I imported a large .obj file and it loaded in about 1/2 a second (SI took over a minute). The viewport seemed at least as fast as SI and rendering was a joy. I will be investigating further, but it's pretty impressive. They're gaining ground fast.
What disappoints me most is SI could have easily had something similar with Iray but instead wasted their time with this wretched HQVP. I've tried many times to use it but it's utterly useless. The scene translation or whatever it's called is so slow it's laughable. It would have to be 50x faster to be any use at all.
Re: How rendering should be
Is that ever true. There's been features handed to them, just sitting there for years that haven't been implemented. Can't imagine how it would change though. MI/Nvidia isn't going to do it for them.Kzin wrote:xsi implementation depends to much on ad at the moment, i hope this will change soon enough.
Re: How rendering should be
And this is the consequence of having an ICE-centric development. Time passes and SI cant keep up with even open source softwares in terms of performance and daily normal operations, not to speak about rendering. And things arent going to change since SI is officially a maya plugin now.
Re: How rendering should be
For a small story, while ago it was a feature called 'open gl shadow map acceleration', or like. By enabling this, it was possible to get a faster shadow map, accelerated by GPU. For small price of memory leaking, whatever graphic card was used. About twenty frames, then only re-start pf machine for another twenty. I think I've tried it with every possible graphic card, including pro ones... MR "feature" was removed in XSI 6, I think.ActionArt wrote:Is that ever true. There's been features handed to them, just sitting there for years that haven't been implemented. Can't imagine how it would change though. MI/Nvidia isn't going to do it for them.Kzin wrote:xsi implementation depends to much on ad at the moment, i hope this will change soon enough.
And THAT is main problem, instead of fixing, there is always a new set of magic words. Once the new magic doesn't work, there's a time for a new round.
Only alive MR implementation beside AD, seems to be Mental Ray for Cinema 4d. Not that much of traffic on their forum, especially compared to one of sites of V-Ray for Cinema. I'm wonder who is guilty this time...
Re: How rendering should be
These sort of features never made any sense to me. Shadow map acceleration? Why accelerate something that's already fast? It's like the current AO pass on the GPU. Who cares? It's already the fastest part of rendering passes. Why not accelerate something that is painful slow now like volume rendering, area light shadows, final gather pass etc.
Iray is getting a lot of development but still no implementation which IMO is just silly. It seems it could be a great visual feeback tool far more useful than the current HQVP.
Iray is getting a lot of development but still no implementation which IMO is just silly. It seems it could be a great visual feeback tool far more useful than the current HQVP.
Re: How rendering should be
area light shadows will be alot faster because of the new importance sampling in 3.11.
working more on fg makes no sense at this stage. ;)
volume rendering is a shader thing. what mi could do is code a general one, but its to custom i think because in vfx alot of shops use their own stuff. in the meanwhile, take a look at emfliud and the ba volume shader which is voxel based.
i agree on iray, alot of users using it for fast previews but progressive rendering would do the same.
ad has stated that they are not interested on iray integration in si.
i dont know what the decisionmaker ad ad thinks about the hq viewportstuff when you have no connection to the current renderer, i dont get it. it would make more sense to integrate iray, especially if you want a future proven solution. but also here, ad stated that the users wants such a solution.
working more on fg makes no sense at this stage. ;)
volume rendering is a shader thing. what mi could do is code a general one, but its to custom i think because in vfx alot of shops use their own stuff. in the meanwhile, take a look at emfliud and the ba volume shader which is voxel based.
i agree on iray, alot of users using it for fast previews but progressive rendering would do the same.
ad has stated that they are not interested on iray integration in si.
i dont know what the decisionmaker ad ad thinks about the hq viewportstuff when you have no connection to the current renderer, i dont get it. it would make more sense to integrate iray, especially if you want a future proven solution. but also here, ad stated that the users wants such a solution.
Re: How rendering should be
I was just thinking of Weta's use of GPU acceleration for area lights on Tin Tin. Looks like Nvidia had a big part in it. That would be useful but highly unlikely it will be a part of SI in the near future.Kzin wrote:area light shadows will be alot faster because of the new importance sampling in 3.11.
I have. So far they're not what I was hoping for and certainly not fast. Also (for me) very confusing and difficult to set up. Volume rendering just seems a natural fit to use the GPU on. I haven't tried the new Fury yet so I will at some point.take a look at emfliud and the ba volume shader which is voxel based.
Progressive is still CPU based though and not exactly fast. In Blender with Cylcles the GPU mode is blazing fast in the viewport even on a old GTX285 like mine. I find it very aggravating that AD doesn't want to get Iray going in SI.i agree on iray, alot of users using it for fast previews but progressive rendering would do the same.
ad has stated that they are not interested on iray integration in si.
I guess I should make it more clear too that I don't mind MR in the final render process, in fact I rather like it as it's so flexible, it' mainly the working and preview area that bothers me the most and the fact that a solution is sitting right there (Iray) and all they have to do is hook it up is the most maddening part.
Last edited by ActionArt on 21 Aug 2012, 05:22, edited 2 times in total.
Re: How rendering should be
The reason why AD doesnt want to implement iRay is mostly due to the work behind it, as it was said many times, taking care of a render engine is quite a job and effort, i have no idea who is now set to this task but the development of Softimage is all focused on ICE, i cant see them swapping time/development/resources/money into taking care of the rendering, this never happened since quite a while, and this is the reason why we are at this mess now.
They rather focus on adding ICE nodes than havin the render engine works properly and with all the features. Not counting that the implementation from AD always lacked of many things, and came also with wrong default parameters which was never fixed, showing quite the lack of knowledge by them on Mental Ray. Reason why who develops a render engine should also be in charge to implement it. But this is another story, AD found on their hands a product they were totally unaware how it works, and it showed by implementations trough those years.
Dont expect to see any news on Softimage rendering anytime soon, AO in gpu? its gonna end up like iRay, not implemented and so on. Bottom line, they dont care about Mental Ray anymore, i am pretty sure in Beta testing no one uses it anymore. Also might as well fix the framebuffer before even attempting to implement something. Those are things and problems that are going on since years and never addressed. There is only one reason for this, they dont care. There is no excuse for some of those things not to work not being integrated, not being fixed after all those years. But hey, they keep taking ur money.
Nice job with the HQ viewport.
They rather focus on adding ICE nodes than havin the render engine works properly and with all the features. Not counting that the implementation from AD always lacked of many things, and came also with wrong default parameters which was never fixed, showing quite the lack of knowledge by them on Mental Ray. Reason why who develops a render engine should also be in charge to implement it. But this is another story, AD found on their hands a product they were totally unaware how it works, and it showed by implementations trough those years.
Dont expect to see any news on Softimage rendering anytime soon, AO in gpu? its gonna end up like iRay, not implemented and so on. Bottom line, they dont care about Mental Ray anymore, i am pretty sure in Beta testing no one uses it anymore. Also might as well fix the framebuffer before even attempting to implement something. Those are things and problems that are going on since years and never addressed. There is only one reason for this, they dont care. There is no excuse for some of those things not to work not being integrated, not being fixed after all those years. But hey, they keep taking ur money.
Nice job with the HQ viewport.
Re: How rendering should be
No kidding. MR will do a half ass job of developing it and AD will never get around to implementing it.Maximus wrote:AO in gpu? its gonna end up like iRay, not implemented and so on.
Whether AD likes it or not, Iray is getting the Lion's share of the effort at MR so if they had any sense they'd get with it.
The only way AD will start to care is if competition (especially free competition) leaves them in the dust. But they won't notice or care until several years later...if then.
Not for long.But hey, they keep taking ur money.
Re: How rendering should be
i understand that gpu rendering is what people wants but keep in mind that mr is for vfx work and gpu is not that flexible then cpu rendering at the moment. because of that, mi goes 2 ways, mr and iray for the moment. there are developements to get over the problems on gpu, so lets see what the next years will happen.
and i dont think gpu rendering is much faster. i am playing aroung with octane render, its great and fast for what is does, but 1080p noisefree renders also take 8-20 hours on my gtx580 for more complex lighting situations.
wetas pantaray solution is complete different. weta renders all the arealights with pantaray, bake it and using this as lookup in renderman. so they using 2 renderer, with renderman a custom solution with all their stuff. i think that only works in a bigger pipeline. i cant imagine how this would help me for example to get faster results. it would be a mess to work with such tools for smaller shops. the interesting thing with pantaray is the amount of data it can handle on gpu. i am pretty sure something like this will find its way into iray. the last update goes more in the production direction. i know it would be great to have this in mr, but at the moment other things have more priority because they are more critical (the whole flexible bsdf stuff and the gi).
ad dont know what to do with mr, thats true. its a big problem and i dont know how this will end.
the alternative is to get string options as soon as possible for xsi so ad dont have to do that much in the future and the user can use the features he wants.
and i dont think gpu rendering is much faster. i am playing aroung with octane render, its great and fast for what is does, but 1080p noisefree renders also take 8-20 hours on my gtx580 for more complex lighting situations.
wetas pantaray solution is complete different. weta renders all the arealights with pantaray, bake it and using this as lookup in renderman. so they using 2 renderer, with renderman a custom solution with all their stuff. i think that only works in a bigger pipeline. i cant imagine how this would help me for example to get faster results. it would be a mess to work with such tools for smaller shops. the interesting thing with pantaray is the amount of data it can handle on gpu. i am pretty sure something like this will find its way into iray. the last update goes more in the production direction. i know it would be great to have this in mr, but at the moment other things have more priority because they are more critical (the whole flexible bsdf stuff and the gi).
ad dont know what to do with mr, thats true. its a big problem and i dont know how this will end.
the alternative is to get string options as soon as possible for xsi so ad dont have to do that much in the future and the user can use the features he wants.
Re: How rendering should be
Yes, cycles is nice too, but is half baked, and many features are not implemented and are only beta (i. e. cycles cannot rendering particles). Actually you can have fast result with GPU, but the big development is under CPU, and they will have, in a year, a fast rendering CPU without memory issue (GPU will be used, if I understood correctly, only for preview purpose), blender developers affirm GPU development is too complex and with too many limits so they started from the beginning cycles like a hybrid cpu/gpu. The viewport preview is very fast (IMHO many steps forward for quality and speed than HQV) , but in opengl is very poor, they have a google summer code project (a totally new rebuild of opengl code for the viewport following the new opengl 2.0 standard) and in blender 2.65 viewport FX will be ready to rock.ActionArt wrote:I recently tried Blender briefly along with Cycles and I now feel we're in the stone age with rendering in SI. I dread learning yet another major ap but it sure seems tempting so far.
I imported a large .obj file and it loaded in about 1/2 a second (SI took over a minute). The viewport seemed at least as fast as SI and rendering was a joy. I will be investigating further, but it's pretty impressive. They're gaining ground fast.
What disappoints me most is SI could have easily had something similar with Iray but instead wasted their time with this wretched HQVP. I've tried many times to use it but it's utterly useless. The scene translation or whatever it's called is so slow it's laughable. It would have to be 50x faster to be any use at all.
I think blender must be respected, sometime I read caustic or hilarious comments about, many think it is not at par only because is free, or the common thought about blender is a not well implement software due to his open source nature where anyone can put his hands for adding this or these other feature. All wrong, blender is one of the most coherency e well structured software out there, his development beginning before maya, and has different paradigms, but it far different from agglomerate plugins like 3dsm because blender foundation has a strong control all over the process (and the process going fast and strong like a train)
I astonish about how fast and user friendly is blender development (and all they are free users...)
Officially Maya plugin? Are sarcastic or is a reality?And things arent going to change since SI is officially a maya plugin now.
IMHO the idea of selling softimage with maya was a good idea (I prefect understood is a open woods in every xsi user pride)
Re: How rendering should be
I think that SI future is more guided towards game industry, same as Maya (look new DX11 viewport), that is reason why HQ viewport was built. It is not important what render engine you have the most important thing is to have viewport similar as possible to game engine output. I think that SI is now oriented to eastern market, and as far as I am familiar with that they use SI mostly for creating gaming assets, correct?
So I am not big optimist with MR and SI also.
So I am not big optimist with MR and SI also.
- H -
Who is online
Users browsing this forum: No registered users and 21 guests