I often see this disscusion about normal maps and they always seem to be a common concensus that normal maps are good for games or animation but when it comes to quality rendering Bump and Displacement maps are far better at giving better results.

I often see this disscusion about normal maps and they always seem to be a common concensus that normal maps are good for games or animation but when it comes to quality rendering Bump and Displacement maps are far better at giving better results.

Thankyou for the reply, to me it seems the level of detail used is a midway between high poly and low poly with the use of bump and displacement maps.

Both the props shown are for use within Unity 3D hence my use of the normal map.

So if I were to increase my current level of detail and use bump and displacement maps would this then be the correct approach?

I could also inclued the normal map within the texture map images, however you would not assign this map within daz studio.

The product would then be marketed for use in unity, altough I do not think daz studio allows the use of the model mesh?

Normal maps are specifically for giving detail to low-poly meshes - think of them as super-bump which reflects light in 3D as opposed to bump maps which only reflect in 2D. The original application was to use a method of transferring the surface detail from a very high poly mesh to a low poly copy. This method gives a lot more detail than a bump map can.

Then came methods of converting 2D images to normal maps - results can be pretty iffy and on the whole I agree with Szark that in general you can get better results using bump maps - it really depends on how well the 2D image is converted.

Displacement needs a pretty dense mesh to get good results and it does that by adding even more actual mesh, so no good if you are using the actual mesh in a game. If you are only using rendered images, then a good displacement map would give you the best results. From what I have read, but never tried, is that Daz Studio gives very good results using displacement - I've never had a decent result in Carrara.

Something that I never see written about in the forum is Hex's ability to export a bump map of a high poly model for use on the low poly original. These can be used as displacement maps or converted to normal maps.

. From what I have read, but never tried, is that Daz Studio gives very good results using displacement - I've never had a decent result in Carrara.
.

Yeah the 3delight render engne is good at transforming a mesh into a higher resolution mesh at render time making good use of displacement maps but as far as I am aware Carrara doesn't. So in Carrara the mesh needs to be a high resolution to effectively use displacement maps. I think I heard on the Carrara grape vine that this was to change in Carrara.

Normal maps are specifically for giving detail to low-poly meshes - think of them as super-bump which reflects light in 3D as opposed to bump maps which only reflect in 2D. The original application was to use a method of transferring the surface detail from a very high poly mesh to a low poly copy. This method gives a lot more detail than a bump map can.

Then came methods of converting 2D images to normal maps - results can be pretty iffy and on the whole I agree with Szark that in general you can get better results using bump maps - it really depends on how well the 2D image is converted.

Displacement needs a pretty dense mesh to get good results and it does that by adding even more actual mesh, so no good if you are using the actual mesh in a game. If you are only using rendered images, then a good displacement map would give you the best results. From what I have read, but never tried, is that Daz Studio gives very good results using displacement - I've never had a decent result in Carrara.

Something that I never see written about in the forum is Hex's ability to export a bump map of a high poly model for use on the low poly original. These can be used as displacement maps or converted to normal maps.

I use Bitmap2Material from Allegorithmic http://www.allegorithmic.com/ but would be intrested in learning more on Hex's ability to export a bump map of a high poly model for use on the low poly original. These can be used as displacement maps or converted to normal maps.

...The bump map can be used in the displacement channel or converted to a normal map.

Converting a bump map to a normal map doesn't make sense to me. What purpose does it serve to convert a 2d map to a 3d map with no additional 3d dimension data (since the 'bump map' only has a 2d dataset.) It would seem that it only makes sense to use a normal map that was created from the original high detail 3d object.

Converting to normal map, you can get some extra artificial detail. I'm thinking here of a brick wall. With a bump map, you get good detail on the face, but the corners show a sharp edge. With it converted to normal, you can get the effect of the bricks at the corner appear to be separated by mortar - not much of a difference, but maybe enough to be more believable.

This I've only mentioned as a curiosity - it really isn't much good and I've never found a useful application for it. Blender does this function far better and if you can understand the highly technical UI and poorly translated Spanish instructions, X-Normal is really good.:)

This I've only mentioned as a curiosity - it really isn't much good and I've never found a useful application for it. Blender does this function far better and if you can understand the highly technical UI and poorly translated Spanish instructions, X-Normal is really good.:)

Thanks Roygee...I have never been able to fathom out the UI on Blender. It makes my head hurt to look at it...

I do have zbrush which you can do really good displacement maps with(at least thats what I've been told. I'm still working on learning how to use it. I was just really suprised as I hadn't noticed it in Hexagon before...

If you have Z-Brush, that is all you need - wish I could afford it:)I bought it through DAZ for about $150 or I would never have been able to afford it either ; ) I think it was either the same year or the year after they had hex for $6. I've had it for a while now. I just wish I had time to sit and learn all the programs I have properly...I'm hanging out until I can retire and play all day with them.
Blender - well...yeah. Whenever I'm feeling brave I dust it off and have a go. Slowly getting to grips with it - I can at least now do a reasonable retopo.

Firstly, any application will place the pivot point - or hot point - in the centre of the bounding box, regardless of where you may have changed it to in the modelling app - that is the nature of the beast.

Daz Studio handles objects very simplistically - it reads it as a single entity. To get the handle bars, with wheels etc. turned, you'd have to do some pretty sophisticated rigging. I doubt very much that Studio has a spin function - although there may be a plugin I don't know about - there are so many:)

Carrara, for instance, gives you the option when importing, to import as a single entity or as groups. You would then group the front wheel assembly, set the pivot point to where the forks meet the frame and pivot the handle bars- this is not possible in Studio. Carrara also has a spin modifier to get the wheels turning.

If this is for a still shot, you should pose the handle gars turned in your modelling app - pretty simple to do in Hex. If it is for animation, you would need to rig it. About the only way to simulate wheels spinning in Studio would be to make a circular plane with a spin blur texture on it.

Just curious - Blender has everything you need to do what you want - why not use it?

Sorry - I know nothing of Poser, so must wait for someone else to jump in. What I do know is that Poser and Studio use pretty much the same rigging system and what you are proposing sounds about right for Studio, so should work. The only problem I foresee is to get the pivot point of the forks in the correct place for the rotation of the handle bars to turn the wheel. Possibly Poser has a method of moving the pivot point - Studio 3 has a plugin that can do this, but I don't know if this was updated for 4.5.

I think you may be making things a LOT more difficult than you have to, Col.

Putting bones on an item in poser requires turning it into a figure, and there's all kinds of crap you have to adjust once you do that.

But a bike is a mechanical device that doesn't need "zones" or anything else to make it work.

A bike is made up of 4 things: 2 wheels, a fork and a frame.

The little section where the fork shaft passes through on the frame is called a "head tube", and is angled around 30 degrees or so.

When you make the fork in hexagon, make it so that the shaft that passes through the head tube is vertical, and aligned at "0" X and "0" Z cordinates. This is VERY important because when you export it as an OBJ and then import it into Poser, the "yRotate" dial will cause the fork to rotate around that point. When you xRotate the fork in Poser so that it aligns with the head tube, the fork's Y-axis will rotate with it, and the fork will rotate (turn) properly in the head tube.

So make your fork as outlined above and export it as an OBJ.

Now make a wheel making sure its center hub is aligned at "0" X and "0" Z, and export it as an OBJ too.

And of course, make your frame, making sure it's aligned at "0" Z (the other axes are irrelevant since the frame will be the main body around which everything else works).

In poser, import your fork.
Now import a wheel.
Align the wheel to the fork, and then parent the wheel to the fork.
This way, the wheel will turn in the fork using the zRotate dial. When you turn the fork using the yRotate dial, the wheel will turn with it.

Now import your frame and the wheel again as the rear wheel.
Align the wheel to the rear fork of the frame and parent the rear wheel to the frame.

Now align the fork to the head tube using your xTran, yTran and zRotate dials. The front wheel will follow the fork.
Once the fork is aligned to the head tube, parent the fork to the frame.

When I say "parent to", that's technically backwards, but I think you know what I mean. In the end you should have the frame as the parent to the rear wheel and also the parent to the fork. The fork should be the parent to the front wheel.

Now when you move the frame, the whole bike goes with it. Turning the fork left or right using the yRotate dial turns the front wheel with it, and each wheel can be rotated using the zRotate dial.

Now you can save the entire bike as a prop and you don't have to worry about bones or anything.

I opened daz and loaded this model into daz, the origin for the wheels is set correctly ie in the middle of each wheel

Just to keep things straight in my own head, by "daz", do you mean daz studio or daz hexagon? When working with multiple daz apps, it's best to signify "DS4" or "hex", etc.

However the origin for the forks I think is not correct. When i move the forks using the y rotate it rotates but away from the bike frame

It's not the origin of the forks that's important here, it's the origin of the axis around which the fork rotates, and I have a feeling this is where you're going astray, which I'll address in the following paragraph.

I do not have a shaft on my forks, I just have a top and bottom...I do not have, The little section where the fork shaft passes through on the frame is called a “head tube”, my forks are aligned at “0” X and “0” Z cordinates. This leads me to think. I need to adjust the point of origin on the forks, before I parent the wheel.

Okay, even though you have no shaft per se, there's still a virtual axis that runs between the handlebars and the wheel fork where the shaft would be if you had one. And this axis is CRITICAL: it MUST be VERTICAL before saving as an OBJ file, AND it must be positioned at 0 X and 0 Z. Remember we're talking about the position of the AXIS, not the entire fork object. This is where Poser gets the Y-axis of the OBJ from when you import it. Once imported, you can rotate the fork section along the Z axis to form the proper angle to the frame, and Poser will automatically maintain the Y-axis along the fork.

I am really sorry for all the mistakes I am making

No apologies necessary - that's what the forums are for, and we love trying to figure this stuff out!! :)

Just did a quick check in DS4.5 - you don't even need to use the joint editor to move the pivot point. Simply select the pivot point and move it to where you want it - even off the model altogether. This opens up a whole new way of doing some things - I'm impressed!

I opened daz and loaded this model into daz, the origin for the wheels is set correctly ie in the middle of each wheel

Just to keep things straight in my own head, by "daz", do you mean daz studio or daz hexagon? When working with multiple daz apps, it's best to signify "DS4" or "hex", etc.

However the origin for the forks I think is not correct. When i move the forks using the y rotate it rotates but away from the bike frame

It's not the origin of the forks that's important here, it's the origin of the axis around which the fork rotates, and I have a feeling this is where you're going astray, which I'll address in the following paragraph.

I do not have a shaft on my forks, I just have a top and bottom...I do not have, The little section where the fork shaft passes through on the frame is called a “head tube”, my forks are aligned at “0” X and “0” Z cordinates. This leads me to think. I need to adjust the point of origin on the forks, before I parent the wheel.

Okay, even though you have no shaft per se, there's still a virtual axis that runs between the handlebars and the wheel fork where the shaft would be if you had one. And this axis is CRITICAL: it MUST be VERTICAL before saving as an OBJ file, AND it must be positioned at 0 X and 0 Z. Remember we're talking about the position of the AXIS, not the entire fork object. This is where Poser gets the Y-axis of the OBJ from when you import it. Once imported, you can rotate the fork section along the Z axis to form the proper angle to the frame, and Poser will automatically maintain the Y-axis along the fork.

I am really sorry for all the mistakes I am making

No apologies necessary - that's what the forums are for, and we love trying to figure this stuff out!! :)

Sorry for the confusion I mean DAZ studio and not hexagon.

Ok, i think

I understand, unfortunate, I have the forks saved with and angle and rotation applied with (the file I am working with).

BTW and FWIW, it may be of use to know that OBJ files are text files. What that means is that you can ZIP/RAR them and make files MUCH smaller than the actual OBJ files are. You'll see what I mean when I return them to you as RAR files.

Okay, now that I've got that off my chest, we can move forward. :)

There's a few problems I've encountered with your model with respect to certain elements not being zero'd with the Z-axis.

For instance, your bike frame is zeroed, but the head tube was not, and neither was the bar the head tube is attached to. These 2 items are shown in my first image. I zeroed them both for you.

Also, from the standpoint of physics, there was another "problem" on the head tube. As shown in my second pic, the ends of the tube were not square-cut to the head tube. In the "real world", this would cause problems with shaft rotation, so I realigned the ends for you as well.

These 2 problems were the only 2 on the frame, but there are many more I found on the fork and that will take me awhile to adjust and document for you. But the good news is that I've already made some cursory checks, and I can tell you that the problem is 100% soluble.

When I'm finished, will I be able to upload my RAR file to you on that website?

...there's still a virtual axis that runs between the handlebars and the wheel fork where the shaft would be if you had one. And this axis is CRITICAL: it MUST be VERTICAL before saving as an OBJ file, AND it must be positioned at 0 X and 0 Z. Remember we're talking about the position of the AXIS, not the entire fork object. This is where Poser gets the Y-axis of the OBJ from when you import it

I've discovered this is only half right. I'm right that the head tube axis (regardless of its being real or virtual) must be vertical prior to saving the fork.

However, I'm dead wrong "about the position of the AXIS, not the entire fork object". Poser doesn't give a damn where the Y axis was located in the source program. Instead, Poser insists on centering the fork around its "center of mass". The equivalent term in hexagon is "bounding box" which does in fact mean "the entire fork object". This means that Poser's center of mass is located slightly forward of the head tube axis, and when you yRotate the fork, the head tube revolves around the errant Y axis.

So I've managed to come up with a way of "tricking" Poser into seeing the center of mass as being down through the center of the head tube instead of down the center of the main fork body. It's a kludge, but it works quite well and the fork now rotates around the head tube.