Forum Replies Created
-
AuthorPosts
-
kubanParticipant
I can’t think of any value of Tezro, other than running flame/smoke on that. If discreet* ports all the software to Linux, nobody will like to have those expensive workstations. But I would dream that SGI’s were 100 times faster than PC’s.
But if we come to onyx4, I don’t think there are too many options in PC, which will support that many processors in one computer. I think the Cray technology is an invaluable information for SGI.
I repeat, Tezro can only be sold, because it can run some very expensive softwares, which are only available on IRIX platform. Other than that, Tezro is only comparable to a US$1k PC! 🙄
kubanParticipantMaybe you just have some premultiply problems with your image? Is the object on a black background? If it is, just select in action, surface blending mode to “add”. This way, you won’t have black borders, but also you can not control transparency.
Let me know, if it is your case.kubanParticipantWe all seem to like the cheaper systems we work on. But if you spend high quality workmenship in your product, and if you put lots of hours of workmenship into it. It will probably be a very good product. But if your clients are counted in hundreds, cost per license will be also high. Can you think the price of WindowsXP per client, if Microsoft sold only 1000 copies? Every client should pay 1/1000 of development cost then. So we are using highend products like discreet* IFFFS, and they have to be expensive.
And we, the artists are also important, because we use that expensive toys. All the artists seem like the product prices going down. But this also means, the artists price is going down. And the workmenship quality is going down. So we shouldn’t be against the highend, high quality systems, just because they are expensive. Can you think any negative side of inferno* other than being expensive?
kubanParticipantBut also when you render an imported 3D object within action, it will premultiply the object with backgorund color. So if you want to composite the action rendered object later. You will have the same black edging problems.
And lets think of another situation, you have 2 transparent images in action, and one of them is crossing over the another one. You render the result & matte of the layers. Later you want to composite this, in another action setup, without loading the original 2 layers. Then you will need the “add” feature again, if you rendered the sequence over black.
Or some particle effects you created in action, which the particles have some color effect, like a flame. Particles change their color over time. Then you have hundreds of transparent layers with different colors. The above problem will appear again. So “add” mode is also usefull in flame*
kubanParticipant>>> Chek
For example if you have got a rendered image with alpha in 3D softwares like softimage, and if the image is rendered over black. You then have black edge problems(or if the objects are transparent, you have black surface problems). So in that kind of situations, you have to set the blending mode to “add”.kubanParticipantYou mean there is a premultiplacation problem with flame* or not? If you select in your surface menu, “blending mode->add” you will have no problems with clips premultiplied over black.
But if rendered over other colors, there are solutions with logic ops.kubanParticipantdo you want to have a pendulum like movement?
kubanParticipantThe geometry you draw within the keyer is called a “Gmask”. In flame* you can save the “GMask” file to the disk. And since the combustion keyer should be 100% compatible with flame*, there should be a save Gmask menu as well. In flame*, it is located under:
Key>Mask>Setup>Gmask SetupsI hope this helps
kubanParticipantguest wrote:Flame 7.x and 8 will not run properly on MXI. It will only run on E series graphics.Hmm, this sounds interesting. Because JFP always told us, the main difference between I and E is speed. So they were the same to software, as far as I remember from Jean Francois Panisset flame-news posts. Do I remember wrong? What may be the cause?
kubanParticipantIf you are using the “geom” option in keyer module. I guess the keyer setup should be 100% compatible with flame* keyer setup. So all your setup can be read into flame* keyer. No need to export anything.
Just read the combustion keyer setup file in flame*PS: I don’t have any experience with combustion. I am telling you this, because I read something about this subject before.
kubanParticipantI guess no one wants to reply this topic.
Years ago, we started a topic similar to this, I think 4-5 years ago. Maybe you can look to flame-news archive. But those salaries might be old for today.kubanParticipantCome on boys. Everybody loves flame* It is great piece of software. I like its workflow. Ofcourse 5 shake seats are much cheaper than 1 flame seat, and shake is much much cheaper, and productive. But if you just need ONE very very powerfull seat, when working with directors, etc.. Flame is great. You can show many effects interactively.
Shake is great for its price, but if you have a good flame artist, get a flame for him/her.kubanParticipantI am not a good shake guy. I am telling you my impressions on shake. First of all, you have to render everything with CPU, when you work with shake. That’s a problem of speed.
Flame: faster, expensive
Shake: slower, cheaperSo that’s a choice of, whether you drive a ferrari, or an opel. If you have the money, if you want race with time. You will buy the ferrari, but the opel may bring you to the same place, but slower both at open road, and curves. But the price is very different.
So the question should be, can we afford a flame? If you can afford a flame, buy it. And get 2-3 shake licenses as addition. The shake systems will cost 10% in total to flame budget. There can be no price comparison between shake and flame. Flame is 50 times expensive.
And v8 is ideal for 3D jobs, now with true resolution independence in flame, things are much more fluent. And the new batch is good. The burn* is the way to render faster. With Gigabit network, data flow is fast, network rendering is efficient.
kubanParticipantAs an old flame* user, I would definetely go flame. But I know it is much more expensive. If the price is not much of a problem, use shake, as a helper tool to flame.
Thats my idea.
kubanParticipantHere are some more additions to the differences:
– Not too many blending modes in surface menu in action. Just blend and add mode. So forget simple add, multiply, spotlight, etc..
– Not too many logicops, just add, subtract, multiply. -
AuthorPosts
