offer for sascha - off topic

General discussion about JPatch

offer for sascha - off topic

Postby J. Baker » Mon Jan 02, 2006 11:37 pm

Hey sascha, your name has came up in the Hash forum. Well, to start off I had made a request for using other renderers in A:M. Long story short, a guy named Rodney from the Hash forum said (if I read it correct) that if you would be interested in creating a plug-in for A:M that could use other renderers, like JPatch does, he would buy you a copy of A:M. I'm sure you're busy with your own project but just thought I would let you know of the offer. Here's the link if you would like to read it yourself, cheers! ... ntry152909
AMD Semprom 2400+ - PQI Turbo 512MB DDR PC2700 - ATI 9100 64MB DDR PCI - Samsung SP0411N - PcChips 848ALU 2.1 - WIN XP Home SP1
J. Baker
Posts: 13
Joined: Sat Jun 12, 2004 6:06 am
Location: USA

Postby dcuny » Tue Jan 03, 2006 5:44 am

I'm (obviously) not Sascha, but I'll throw my own 2 cents in. :)

First of all, I doubt that people really want to use Yafray with A:M. It's just too slow a renderer to use with animation. (Not entirely true - I read recently that one renderfarm for hire was going to support Blender+Yafray. But I'll ignore that. ;)).

If you're aiming for generaing a still image with an A:M model, use JPatch to export the model to .obj format, and import it into Blender. Sunflow is also an excellent renderer which recently got Blender support, and Art of Illusion can import .obj format.

If you want to do animation, the only practical thing would be to have A:M calculate each frame, and then export the geometry information. Otherwise, you'd have to reverse engineer all of the smartskin stuff, the channel effects... It's just not practical.

If you did this, you've still got a major issue: getting materials to work. That is, you'd need to export information about color, specularity, bumpmaps, and so on.

You could do this if you exported u/v maps for each object. It would sort of be the u/v map process in reverse: instead of looking at a point of an object and mapping to u/v space, you'd iterate through a u/v map and ask A:M for the attributes. That way, you could unify things like dynamically calculated textures, decals, and so on.

But that would require pretty low-level access to A:M, and can't see Hash's motivation for doing that.

If I were Hash, I'd instead be asking my users what specific features from those renderers they were looking for.

Which leads to the obvious question: what are the features that the Hash renderer doesn't support? I was under the impression that it already supported global illumination via photon maps, and could fake it (with spinning lights rigs). It's got a raytracer, so reflection, refraction, and so on should be supported. If you've got a raytracer, it's pretty trivial to add ambient occlusion, and subsurface scattering isn't that terribly difficult either.

It seems to me that the better approach would be to ask Hash to expose the geometry via an API, which would allow people to write a plug-in renderer for A:M.

Now, that's something that would be very, very cool.

That's pretty much what JPatch does with my Inyo raytracer. One nice thing about that is that Inyo is able to ask JPatch for u/v mapping information. That means that once JPatch support u/v maps, Inyo gets them "for free" - I don't have to care if JPatch supports "real" u/v maps, or implements A:M style decals - all Inyo has to ask is for an attribute of a given point.

Similarly, A:M could hide most of the details behind an API. The renderer could ask for an attribute of a particular point, and A:M would return the value. The renderer wouldn't care if it was a base color, calculated attribute, or something from a varying channel - it would just return the value.

I think this would serve the A:M community much better in the long run. That way, if people wanted an alternate renderer, they could write their own (much like the Yafray was written) and add features as they saw fit. That's much less of a "Mission to Mars" request to Hash.
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sun Jan 08, 2006 10:57 pm

Hi J. Baker, thanks for your message.

Firstly, my apoligies for not replying earlier - I somehow missed this message.

As David and Rodney (from the Hash forum) pointed out, JPatch is not A:M. It uses splines and patches, and thus many tools work and look much like their A:M counterparts - but I think this is inevitable - most polygon modelers share the typical poly-modeling tools too. But that's where the similarity ends. JPatch can import A:M geometry, but e.g. can't import A:M materials (I try to focus on RenderMan and POV-Ray, so A:M matrials aren't even on my todo-list), rigs, actions, choreographies, etc.

About that offer: Thank you for letting me know about it, but I'm not interested. I develop JPatch in my spare-time "just for fun". I have a Job and could afford buying A:M, I just never felt the need for doing so (which maybe makes sense, this way I'm less tempted to reverse engineer A:M :wink: ) - this does in now way mean that I have anything against A:M - I'm sure that it is a great program and the price seems to be more than fair.
I'm also afraid that I can't be of much help - I'm a Java programmer, my expirence with C/C++ is very limited, and I have absolutely no expirence with Hash's SDK.

You could try to import A:M models into JPatch (0.4) and export them as Alias|Wavefront (.obj) files (don't forget to "align" the patches before exporting). This format can be easily converted into any other polygon based formats, I'm sure that there are a lot of free converters available. But this features is quite experimental, and it does not export u/v maps or materials (other than colors).
Site Admin
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Return to General discussion

Who is online

Users browsing this forum: No registered users and 1 guest