Attached Link: http://members.shaw.ca/zekaric/arch.zip

Here's the scene. The car file can be found at the given url. Row 1: shader used in bump channel. Row 2: shader used in colour channel. Col 1: veloute Col 2: formula Col 3: brick Colour channel for the brick case didn't seem to do a thing. Odd. Anyhoo. The veloute in bump channel worked as I expected. The formula case doesn't look at all like the color channel even though the formula is exactly the same. The brick has the shown problem tha the creases are light instead of being dark and the surfaces are dark instead of light. I also tried changing the brick to be in combination with a mixer operator. Meaning. Bump: Mixer - Source 1: 100 - Source 2: 0 - Blender: brick It gave a different result but the result was still incorrect, or at least not what I was hoping for.

I have veloute 1. I'll try to reduce the scene and post it here. Currently the scene is 57MB. That's a tad much. ;) Render settings are irrelevant. GI, no GI, ray tracing, no ray tracing, pixel accuracy for shadows, object etc. do no change the fact that the arches are displayed improperly. There are 2 lights and they are roughly close together near the center of the four visible pillars. Total intensity amounts to 100%. It should all become evident (I hope) when I post the carrara file. It could well be that the vertex model for the arch is partly responsible for the problem but for the most part it looks fine to me.

Tried that just now. The result looks like the image with no bump mapping which really doesn't make a hell of a lot os sense to me.

Further investigation... Reconfirmed that it does happen with GI turned off. For a second there I thought I'd be making a fool of myself.

Decided to try a different shader instead of brick. Veloute tools' 2D gradient worked rather well. Although I was looking for a slightly more understated effect than the one it gave me. I couldn't make the transition 'fine' enough.

I tried Anything Grooves on the beast but it made a hash of the mesh. Also, to get the understated look that I'm gunning for, the UV sampling would really need to be cranked up and that would make a huge mesh or a long time to calculate. Anyway, the generated mesh was unusable so the point is moot.

Ended up going with the following formula

a = u * 2;
a = a * 13;
a = mod(a, 1);
b = ((0.01 < a && a < 0.99) ? 1 : 0.5);
value = b;

And found out that formulae also don't behave as you'd expect in the bump channel. Not as hideous as the brick but not really close to what I expected from seeing the same formula shader in the color channel. Sigh, looks like I'll just leave it part of the color channel and hope that it'll be enough. If not then I'll compromise and use the veloute 2D gradient.

Thanks

Message edited on: 04/15/2005 00:43

I've rendered with GI/indirect lighting and without. Unfortunately doesn't appear to make a difference. I'll try some other render options to see if they help. I also tried flipping normals in the vertex editor to see if that was the issue. Didn't appear to make a difference though. :/

Now the image without bump mapping. Something much closer to what I was expecting to see instead of the dark side conversion.

This is one of the more frustating things I find about Carrara, but once you get in the habit it's not so bad. What Carrara revolves around is the selected geometry (or element(s) in the assembly room.) So make sure you select something before rotating the scene.

From the looks of it the bones in the middle finger are still acting on the points of the index finger. Remove the middle finger bones from the points of the index finger and the finger should bend as you expect.

Someone correct me if I'm wrong but most game models are vertex/mesh based. Carrara Basics Or non pro versions don't come with the vertex modeller. Or you might check before giving out money.

Were you looking to do something like this?

http://members.shaw.ca/zekaric/gallery/200306_architecture.jpg
http://members.shaw.ca/zekaric/gallery/200312_trish.jpg

The first I did outside. I, like you, decided to take a topo and use that, exported to dxf and imported into another program to do the intersections.

The second I did entirely in Carrara 3. The only problem is that, when you convert a topo to vector, it only converts the preview representation to vector, not the final so you don't get as fine a detail as you might want. Something that annoyed me, but with clever texture mapping you may be able to fudge that.

When you extrude the boundary, make sure you close the other end and that it's a solid. Both pieces should be leak tight solids. (Ok they might not need to but from my experience with other software that does similar tasks, it's generally a good idea as the program won't be confused about what's in and out.) Also make sure that it extends completely around the outside of the other object so there is only one instersection area.

Note, Carrara usually does a good job but I've hit cases where it left some openings which you may need to patch up. This isn't a simple process for computers to do reliably even though it might sound simple in theory. There are a lot of edge cases that can cause grief and floating point precision can make a bright day very dark.

I tried bones in V2 and I hit something like 5 bugs with it. Very very annoying experience. I haven't yet tried the same experiments with V4.

From what I remember.

• Undo is not your friend, it will make things worse and you won't be able to recover from the undo so don't use it. In my case I make a bend with some bones. Don't like it. Undo, and what do you know, the constraint settings were undone but the mesh didn't change. Changing the constraints again causes the mesh to deform from it's current possition. Return to default/start state doesn't help as the constraints are totally fubarred at that point.

• Removing a constraint once it's given a value, I.E. the mesh had been deformed would cause the mesh to stay where it was instead of returning to a state where there wasn't a constraint.

• Sometimes, often, after a whole bunch of bending and posing the return to default/start state doesn't return it to the default state but a wonky one, not the one you started with.

• One of the constraints didn't work right at all in a particular setting (there is one with an order of op in the rotations but the first two were treated the same even though they weren't the same and I don't think it updated the mesh properly)

It's a problem with C v2. Not you. I've hit the same frustrations. I gave up after starting over again and again, rebuilding the skelleton again and again, cursing and waving a certain finger at the screen again and again... It just isn't there in V2.

Message edited on: 01/21/2005 17:35

Texture a plane in the background will work if the cloud is sufficiently distant and/or the image/animation doesn't move around it's point of view to expose this cloud as a textured plane.

Another method, taken from the POVRAY folks, is to layer a few planes with similar noise pattern and the shader is semi transparent as well. This way we are sort of simulating the light through cloudy layers. Carrara doesn't do this all that well because of limited recursion depth. I.E. it stops at 25-28 levels. Not really enough to get realistic effects but with some playing you might get something usable. It will significantly slow down the rendering though.

Message edited on: 09/07/2004 12:43

Daz's product is in it's first generation so it has some ways to go to be up to par with Poser. However Poser has a history for being buggy and it's general reputation and that of the company that programmed it or updated it is not that stellar. Those who have become tired of Poser may just be annoyed enough to try Daz and stick it out. Daz currently holds a good reputation with the community and so people may just give them time and a chance. I don't think Eovia will buy Vue either. Vue seems to have a strong following and I don't see that company giving up control. Unless I'm missing some insider information or 'rumours'. :) I'd like to see Carrara work closer with these other products but personally, Eovia would probably be better off to augment Carrara themselves with the features it lacks in the areas of interest that these other product seem to excell in. This way they keep adding functionality to the product and ensure it's longevity. Vue, Bryce, Mojoworld (etc.) do have some abilities that Carrara has trouble with so there is still some attraction in using these other products. Although I have no arguments to back that statement up but for those who have used them, they would fight for them. I see Carrara still behind compared to other products so Eovia has enough on their own plate with enhancements to Carrara and Amapi to keep them busy for quite a few years to come.

Probably a good thing. If a company diversifies too much they can't spend enough time on their bread and butter apps to keep them going properly. Spreading themselves too thin. The end result will be all products languishing behind their competitors and killing their cash flow on product upgrades etc. Also, what more can they do to improve Bryce and if they could do something, will it give them return on their investment, meaning will the loyalist return to using Bryce or will they jump to Vue or something. Eovia probably knows something about this when they took over Carrara but Carrara was still rather young and immensly expandable. Bryce is fairly mature and I would figure somewhat more difficult to expand on. Eovia may not be in the position to spend millions or go in debt to puchase the product. And Bryce my have a loyal following but it's a declining user base. In my opinion, very risky to buy. I'm a bit surprised with DAZ3D buying it as I see them being a smaller company than Eovia but maybe they have their reasons or my perception is way off. I.E. snap up the bryce rendering engine or techniques, importing code etc. Who knows.

I'm not putting up a forum on my website! Never!

;)

(next task, put forum up on web site.)

I didn't say that. I'm just saying there's too many sites for Carrara discussions. A lot of effort to inspect all of them.