Hello from Hiroshima, Japan

shigekazuishihara's picture

Hello, all of Quartz Composer masters.

I am Shigekazu Ishihara, Prof. at Dept. of Kansei Design, Hiroshima International University. I am researching Ergonomics and Kansei Engineering. I and one of my Ph.D students have been developed systems for "virtual prototyping", those utilized Bump mapping for expressing detailed surface of products. Since he got his job as a lecturer at a college far from here, I have to continue to develop those systems only by myself.

It was good for me, recently I found QC can easily handle GLSL codes. Now I am trying many examples written by QC masters who are gathering in this Kineme forum.

Thanks a lot for QC masters !

I found today, to importing 3D object, even it is in Collada format, using Kineme3D is better than QC native "Mesh importer". When I applied bump mapping on an imported object, the object imported with QC Mesh importer (and Mesh renderer) does not reflect bump mapping. Importing with Kimene3D, it reflected bumps on its surface, as I expected, (as common 3D softwares).

Thanks Kineme3D!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

franz's picture
Re: Hello from Hiroshima, Japan

hello and welcome !

rinboku's picture
Re: Hello from Hiroshima, Japan

Hello! I am glad that Japanese friends increase.

cybero's picture
Re: Hello from Hiroshima, Japan

Hi, Shigekazu.

Yeah, the Kineme 3D texturises more sensibly and effectively than the Mesh Importer patch / Renderer combination, although one can use the Mesh Creator to load in a texture, which more often than not, does work - see 3D Bat Etra for an example of texturised DAE, scaled, unscaled, static and dynamic, using Apple's own tools.

//Post Script// The lack of a DAE with correct textual co-ordinates is, I believe, what causes the problem you are experiencing , Shigekazu.

Similarly, any success you are experiencing is probably due to the files you've got having the appropriate information in them already, I find that what the Mesh Renderer scales and renders is not always possible for the Kineme 3D Renderer to do justice to and similarly, one can find that the Kineme 3D Renderer will do a bang up job on other DAE files, as well as other file formats.

See this attached example [DAE Dysfunctional] for how DAE can and sometimes can't work Mesh or 3D Renderer :-) & see the other attached example [Dice, from Owl Bank] for a DAE that can be rendered well in either patch type.

PreviewAttachmentSize
Dice44.83 KB
DAE_Dysfunctional895.67 KB

gtoledo3's picture
Re: Hello from Hiroshima, Japan

The issue wasn't texturing; the issue was whether the render patch respected bump mapping with GLSL when in a GLSL environment. K3D does, whereas the CL Mesh renderer doesn't. It probably isn't a file/model issue.

cybero's picture
Re: Hello from Hiroshima, Japan

Actually, I have found one way in which Mesh Renderer renders the GLSL ascribed texture - see attached example, uses the Dimple GLSL shader .

Of course that then covers up any other image feed.

Is there a specific GLSL bump mapping issue ?

The behaviour resulting from Mesh renderers in GLSL shaders has been proving to be - well un-predicatable to me at least, but thus far, this way of making the mesh receive a texture.

One thing is for sure - the Kineme 3D Loader renders far more reliably in a GLSL environment than the Mesh Importer currently does.

Although the example presented here textures as per the GLSL shader code, it does not mean that each and every GLSL shader I have tried this Mesh work around with results in worthwhile success. Some have worked. Others produce rather alarming & occasionally delightful results- see the attached rework of ocean.

I'm quite sure that much of the problem with the second of the two mesh renderers included in both example compositions is simply that I have not written in the correct u, v texture co-ordinates to provide the Mesh Creator patch with.

I wonder why the Ocean rework renders the Mesh Creator patch 'badly' as expected, yet renders the Set Mesh texture version unlike the 3d Loader, whilst the Dimple GLSL Set Mesh texture mesh renders AOK?

Still, maybe I'm completely misunderstanding something here, perhaps bump mapping is some kind of hurdle GLSL wise for QC, I hadn't really tracked that - apologies to you, Shigekazu, if I went of on an unrelated tangent concerning your introductory post.

PreviewAttachmentSize
MeshGLSL.zip195.91 KB

gtoledo3's picture
Re: Hello from Hiroshima, Japan

Doing a Dimple GLSL isn't the same as a Bump Map GLSL shader, which makes things look like they actually are "bumped out" from a texture input on a GLSL Shader environment. The Dimple shader doesn't have a texture input. While it "looks" textured from one standpoint, it's not what is meant by having a GLSL that makes a bump map from texture(s).

What the problem is with your Water GLSL example is that you have the one mesh chain going through the mesh creator macro, after breaking up components. The DAE is already a mesh, so it doesn't really need to run through that for any reason. Secondly, you have that mesh creator set so that it is drawing Triangle strips; check your settings.

Set mesh texture is for introducing a modified or different texture into the DAE pipeline. That's also unneeded in the context of something that is inside of a GLSL macro, since you won't see it. Also, in this case, it's not piping any image in, so if it was outside of the GLSL it would also not really be needed either.

You don't need to do any set mesh, or create mesh stuff for this... just plugin the mesh importer straight into the renderer.

None of that quite has to do with Bump Mapping though. I remember there was a really good topic about that around here, and I believe that a couple people posted some interesting takes on that. There is a good reference on bump mapping, and different types, on Bourke's site, I believe.

Yes, sorry about the sidetrack.

Welcome to the forum Shigekazu!

shigekazuishihara's picture
Thanks Gurus (Re: Hello from Hiroshima, Japan

Thanks QC and GLSL Gurus.

I think I could not reply all of excellent suggestions and discussions, but I put some my trials.

"myBumpMapWithTexture" is based on GLSL codes from Toneburst of "Machines don't care blog" (am I right? If I made mistake on his name, pls notice).

I modified the codes several time during my study, but I believe uploaded one has exactly same code by him. Normal map and texture were borrowed from Normal Maps tutorial of oZone3D.net http://www.ozone3d.net/tutorials/normal_map.php

Then, I tried to map on non-built in mesh model in QC, I tried to read some collada files and failed, finally I found Kineme3D is best for do it.

"myBumpMapWithTextureColladaWithKineme3D" sphere.dae was borrowed from Collada.org. https://collada.org/owl/browse.php?sess=0&parent=128&expand=1&order=name...

Along with spotlight movement right and left, the stone texture seems move. I believe that is inherent to bump mapping.

Finally, I attached a successed case of Mesh Renderer of QC on importing Collada file with complex texture. See "myColladaTestNegiMiku". Apparently, it's texture is very complicated. Look miku.png in negimiku folder. Negi and Miku collada data were borrowed from here. http://blog.r3c7.net/?p=121

I am quite beginner of GLSL, so have not words about its structure, but thinking about pipeline during programming is complicated. I am examining with GLSL examples on the net now.

Thanks to gurus.

cybero's picture
Re: Hello from Hiroshima, Japan

Got it, thanks for the feedback.

You're a knowledgeable & patient fellow, GT.

Given the results I get today, I think even more so, but, in my defence, I was getting different results with one of the Mesh Renderer patches yesterday.

I wish I'd done a screen grab of when I was meandering down the dimpled glsls route :-).

Puzzlingly enough, yesterday I had three appropriately textured cubes and one incorrectly textured - 2 Kineme 3D and 1 Mesh Renderer, this is what gave me cause to think I'd achieved proper rendering by one Mesh Renderer.

Today, just for badness' sake •~, I get the altogether more predictable GLSL failures of one sort or another upon both Mesh Renderer patches in any GLSL shader environment I put them into.

If I get a recurrence I shall certainly screen grab.

I now think it would be even worthier of reporting, even if it is pointing actually at a fluke that isn't meant to be supportable and achievable.

With the ocean GLSL [ found on s.roza's post http://kineme.net/Discussion/DevelopingCompositions/GLSLOceanShader ] I was actually getting a really wild effect on the same Set Mesh Texture cube that had been correctly dimpled. It was getting to be a wee bit fractal [& nice].

Just wondering, could all this be cache related to having tweaked and sped up by dumbing down the other GLSL item - Mandlebox - which was running in the background from time to time.

Today, that cube now renders as per the two 3D Loader cubes and the Mesh Creator cube shows it's lacking texture co-ordinates [piping the Texture Co-Ordinates the Normals feed, just doesn't cut it] .

Now it's all flat through Set Mesh Texture and lacking co-ordinates as a straight feed.

Predictable.

cybero's picture
Re: Thanks Gurus (Re: Hello from Hiroshima, Japan

Having proven the scenario for GLSL & Mesh failure to myself, I then managed to reproduce the means by which success was seemingly achieved and also the resulting sweet effects due to the dynamic nature of the ocean GLSL shader.

I have subsequently redrafted your works and updated mine to prove the scenario, so far as I can tell, for some means of appropriating GLSL shader texturing. It does tend to knock out any other texture.

is a quick screen grab to some of the results, obtained just before a brief power outage. I shall have to recreate the file again, although I do have the version without the use of the Kineme 3D Structure Renderer, which other version does render the model in 3D and take a texture from the GLSL shader.

I found that the dice DAE needed its texture image to appropriate any real GLSL action from toneburst's GLSL shader, whilst your DAE needed no such support, although, it wouldn't render correctly via the Kineme 3D loader.

I was going to post the redraftings here, but at over 10 MB, I thought a link to a zip file from my site would suffice. Does it GLSL?.

One thing is for sure, the Kineme 3D Loaders are far more appropriately responsive to the dynamics and parameters of the GLSL shader & it's inputs.

No real bump mapping in the ocean example upon the Mesh Renderers. When I look again, no real bump mapping as such upon the DAEGLSL clip, just seemed that way due to the nature of the normals and plain texture file fed into toneburt's bump map GLSL shader.

shigekazuishihara's picture
Re: Thanks Gurus (Re: Hello from Hiroshima, Japan

Thanks for your experiments. Since both models in Collada was not created by me, I could not reply texturing of these models.

I think I have to make my own models have textures on them, using numbers of 3D modelers.

Shige

psonice's picture
Re: Hello from Hiroshima, Japan

Hello Shigekazu-san! And welcome to QC. It's a good community here (the apple QC mailing list is good too for non-kineme questions).

QC is excellent for prototyping. Well, not always, but for some cases it is the best tool available I think. What is it you're prototyping?

Personally, I use it mostly for video/image processing recently, so I've not even seen k3d yet. Mostly astronomy work - I'm writing an astrophotography application that processes sequences of images or live video from a telescope to make high quality images. Also a side project to detect asteroids in sequences of images. I use QC in plugins for the processing stages, for convenient GLSL/core image. I also use QC lots for 'fun' or 'demoscene' work, and sometimes do contract work with QC (less recently, I've been doing a lot of iPhone development for people instead).

Do you know if there is much demand for QC work in Japan? My wife and I want to live and work in Japan for a year or two (we have friends in Osaka), but it seems the economy is bad and it's difficult to find work except teaching english (which I can do, but it seems a waste of skills :)

toneburst's picture
Re: Hello from Hiroshima, Japan

Hiya, just wanted to add my voice to the chorus of welcome here. Welcome to Kineme!

Apologies if this has been covered already (haven't had time to read through the whole thread), but I don't think bump-mapping is possible in QC, as to make it work, you need access to per-vertex attributes (tangent and binormal vectors) in a GLSL shader that aren't passed accessible in the QC environment. I'd be really surprised, based on conversations with cwright about this in the past, if using Kineme3D made any difference to this.

Sorry to be the bearer of bad news, but happy to be proved wrong.

a|x

gtoledo3's picture
Re: Hello from Hiroshima, Japan

I can't find it, but didn't Dust post a good bump mapping example long ago (or was it parallax... too long ago, and I can't remember)?

I do know that there are cases when Kineme3D responds to the built in Lighting/Shadow engine better than Apple's or other renderers, so I guess I wasn't surprised for someone to throw out there that they were getting better results with K3D.

toneburst's picture
Re: Hello from Hiroshima, Japan

I can't remember anyone doing a properly-working bump/parallax-mapping example in QC, to be honest, but someone may have. I'm pretty sure K3D doesn't have any builtin support for bump-mapping or normal-mapping. I'm also pretty sure that tangent/bitangent (I called this 'binormal' in my previous post, which is apparently incorrect) vectors aren't calculated and made accessible to GLSL shaders in QC by the Kineme3D mesh-import plugin. There are ways of approximating the required vectors in QC, but I've not seen these methods actually working in practice.

For an explanation of tangent, normal and bitangent vectors, see http://jerome.jouvie.free.fr/OpenGl/Lessons/Lesson8.php

a|x

gtoledo3's picture
Re: Hello from Hiroshima, Japan

Understood - I'm aware that tangent/bitangent isn't supported with GLSL in QC, but I wasn't aware that there were no other legitimate approaches. Point taken.

Boy, I sure wish I could find this great page that went through many examples, and talked about the differences between bump, parallax, etc. and was well illustrated. I thought it may have been on Bourke's site, but I can't find it.

toneburst's picture
Re: Hello from Hiroshima, Japan

I found a description of a method for calculating the TBN matrix in a shader the other day. Can't find it again right now though.

a|x