Hi Farshid,
I just added the support for normal map details in the description
string. The format is the following:
Normal unit amount method flip_red flip_green swap_red_green
The method field can be one of the following strings:
Tangent
Local XYZ
Screen
World
Try it out and let me know if
Hi Jean-Sébastien,
On Thu, May 26, 2011 at 6:31 AM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
I tried this, and I notice it's an extra line in the material description
string. I'm wondering why you didn't just put the extra attributes at the
end of the Map ... line for the
Hi Luca,
On Thu, May 19, 2011 at 11:59 PM, Luca Vezzadini
luca.vezzad...@gmail.comwrote:
That would be perfect, so go ahead with that.
I just added the support for normal map details in the description string.
The format is the following:
Normal unit amount method flip_red flip_green
Farshid Lashkari wrote:
Normal unit amount method
Normal 2 1.0 Tangent
[...]
Does this sound reasonable to you?
That would be perfect, so go ahead with that.
Thanks,
Luca
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=39590#39590
Hi Farshid,
I gave it a try, the description lines are there. I just see a minor issue: you
did not add the MaterialData.{h,cpp} to Cmake.
About the results, looks like what is there is fine! I'll do more testing in
the next days, trying to use the definitions in my shaders as well, and let you
Hi guys,
Cool that this is done, I'll check it out soon and try reading the files
back in our engine.
Thanks a lot for your work!
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
Hi Luca,
On Thu, May 19, 2011 at 12:59 AM, Luca Vezzadini
luca.vezzad...@gmail.comwrote:
I gave it a try, the description lines are there. I just see a minor issue:
you did not add the MaterialData.{h,cpp} to Cmake.
About the results, looks like what is there is fine! I'll do more testing
in
Hi Farshid, hi Jean-Sébastien,
I'll let you choose the separator, even if I'd vote for tabs or vertical bars,
not spaces.
About where to place the descriptions and the syntax for them, let's keep in
mind that each description is treated as a separate string, so I'd say each one
must bring all
Hi Luca,
On Wed, May 18, 2011 at 3:24 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote:
About where to place the descriptions and the syntax for them, let's keep
in mind that each description is treated as a separate string, so I'd say
each one must bring all the info it needs. Which now
Farshid Lashkari wrote:
Regarding the format, are you suggesting that there should be a single
description string that contains information for all the materials? Or each
material should still be a separate description, but include the material
name on each map entry line?
I'm suggesting
Hi Luca,
On Wed, May 18, 2011 at 8:02 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote:
I'm suggesting that we have one line per each map; so if you have 5
materials each with 3 maps you'll see 15 description lines in total. And
each line should include the material ID it refers to so it's
Hi Luca,
I've just committed support for the material description strings. Each
material will have its own description string added to the root node. Here
is a sample description:
# osgmaxexp material data
Name Basketball
Map Diffuse 0 1 images\bball_diffuse.jpg
Map Bump 1 0.3
Farshid Lashkari wrote:
# osgmaxexp material data
Name Basketball
Map Diffuse 0 1 imagesbball_diffuse.jpg
Map Bump1 0.3 imagesbball_normal.jpg
Cool! I'll give it a try tomorrow (I'm in Europe, different time...). Just to
be sure I've got it right, the
On Wed, May 18, 2011 at 1:06 PM, Luca Vezzadini luca.vezzad...@gmail.comwrote:
Cool! I'll give it a try tomorrow (I'm in Europe, different time...). Just
to be sure I've got it right, the fields after the keyword Map are, in
order: map name, tx unit, blend amount (in [0,1] range), file name.
Ciao,
So, looks like we have a decision, cool!
To summarize, if I've got it right, for every texture map in the material we
will find a description string like the following (assuming we use the | as a
separator):
Diffuse|Unit_0|c:\program files\whatever\file.png|80
where:
- the first field is
vezza wrote:
About bump, as far as I know Max allows you to create for that channel a map
of type normal and therefore you should be able to distinguish between
regular bump mapping and normal mapping. Actually Max allows even to specify
what space to use for the normal map (tangent,
Hi Guys
Been following this with interest. Having a method to know what map type is
in what texture unit will be great. Regarding the normal mapping, is there
any chance of getting the exporter to also generate tangent vectors (either
from max or using osgUtils). Would be ace if you could also
Farshid Lashkari wrote:
The description would be added to the osg::StateSet object. Our use of the
word material is referring to the Max material object.
Mmm... StateSet does not derive from osg::Node so it does not have the
DescriptionList member... So are you planning to extend the
Hi Luca,
On Tue, May 17, 2011 at 4:29 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote:
I've made a few tests with the current (trunk) version of the exporter and
I'd say it doesn't handle the normal maps for now. In Max, to use a normal
map you don't assign directly a bitmap to the bump
Hi Luca,
On Tue, May 17, 2011 at 6:12 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote:
Mmm... StateSet does not derive from osg::Node so it does not have the
DescriptionList member... So are you planning to extend the StateSet class,
its serializer and so on? Or did I miss something?...
Hi Farshid, Luca,
You are absolutely right! I had mistakenly assumed that the description
list was supported by all osg::Object derived classes. Well, that puts a
big dent in our plans :(
Argh, I had made the same assumption.
Does anybody know if the new meta-data system will support all
Hi,
I have no idea about the new metadata stuff. But if that doesn't work, wouldn't
it be easier to just move the description stuff from Node to Object? The name
is already in the Object class, having the description there too would make a
lot of sense anyway. And I don't this this would be a
Hi Luca, Jean-Sébastien
On Tue, May 17, 2011 at 12:46 PM, Luca Vezzadini
luca.vezzad...@gmail.comwrote:
I have no idea about the new metadata stuff. But if that doesn't work,
wouldn't it be easier to just move the description stuff from Node to
Object? The name is already in the Object class,
Hi Farshid,
If the new meta-data system is going to support all osg::Object derived
classes, then all we need to do is just wait until it is complete. I
think the bigger issue is being able to support older versions of osg
and older formats like .osg/.ive.
Yes.
How about adding all the
Hi Jean-Sébastien,
On Tue, May 17, 2011 at 4:16 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
I would prefer to add it to the description string of the node(s) on which
a material is applied, since a model might have multiple materials on
different nodes... i.e. your way
Hi Farshid,
The exporter applies the material statesets to the osg::Drawable object,
which does not support description strings. I can add the description to
the parent osg::Geode. However, keep in mind that the geode can contain
multiple drawables, where each drawable has a unique material
Hi,
I'd like to share a few comments about the OSGExp for Max (I've recently sent
them directly to Farshid, and also on the Delta3D forum, but it's probably
better to share them here).
I see a few limitations right now and the main ones are the following:
- you can only export diffuse and light
Hi Luca,
On Mon, May 16, 2011 at 4:44 AM, Luca Vezzadini luca.vezzad...@gmail.comwrote:
I'd like to share a few comments about the OSGExp for Max (I've recently
sent them directly to Farshid, and also on the Delta3D forum, but it's
probably better to share them here).
I responded to your
Hi Farshid,
Thanks for the reply; about the new version that can export all maps, that is
surely great news, I'll have a look as soon as possible and get back with
feedback.
Farshid Lashkari wrote:
I have two ideas to help with this issue:
1) Add an option that will use fixed texture
Hi Luca,
On Mon, May 16, 2011 at 1:57 PM, Luca Vezzadini luca.vezzad...@gmail.comwrote:
I'd say that both options are interesting; the first one is probably more
straightforward, but it's true that the second one opens more possibilities.
What about a radio button in the exporter options to
Farshid Lashkari wrote:
I'd like to avoid the first method, since it introduces a couple issues. As I
mentioned in my last email, how would composite materials be handled? Should
the assigned texture unit for each map type be customizable, and if so, how
would the interface for assigning
Farshid Lashkari wrote:
Should the assigned texture unit for each map type be customizable, and if
so, how would the interface for assigning the texture units work?
About the texture unit - map type mapping, is that something that you
really need on a per-material basis or is it more of a
Hi Farshid,
The second method doesn't necessarily need to be an option. I don't see
any harm in always adding a description string to the stateset. My main
concern is coming up with a format that can be easy to parse.
I totally agree.
I'd like to avoid the first method, since it introduces
Hi Luca,
On Mon, May 16, 2011 at 3:39 PM, Luca Vezzadini luca.vezzad...@gmail.comwrote:
About the texture unit - map type mapping, is that something that you
really need on a per-material basis or is it more of a global definition for
you whole file? I would say it's more a global thing. If
Hi Jean-Sébastien,
On Mon, May 16, 2011 at 3:58 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
In the case of our use of the exporter, we'd want to implement the second
case anyways, as our engine uses specific shaders and a pipeline that the
exporter doesn't (and shouldn't)
We could probably start off with the hardcoded version first, then later on add
the customizable version. Baby steps... :)
About the description syntax, I think the main decision is: is this a
Max-specific feature or do we want it to be generic? Generic would be better of
course but then we
Hi Farshid,
Same here, our application already determines texture units at runtime,
so I personally have no need for hard-coded units. Do you have any
suggestions for how the material description strings should be formatted?
Both your and Luca's suggestions are good, but I think I like Luca's
Hi Jean-Sébastien,
On Mon, May 16, 2011 at 4:56 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Both your and Luca's suggestions are good, but I think I like Luca's
better, as it doesn't assume any ID number (yours has Type_0, Type_1, ...
which seems to suggest a certain
Hi Farshid,
I personally don't need them, but if a hard-coded texture unit option
were to be added to the exporter in the future, then we might as well
add this information to the description string now. If we are 100% sure
that this option will never be added, then I'm fine with leaving this
Hi Farshid,
1) Adding prefix/suffix to image filename. I believe this is the easiest
method. The filename will be applied to the exported osg::Image object.
For example, you can append _[normal] to all normal map images.
I think this is a bit too intrusive. The artist should be able to name
Hi Javier,
I have to get deeper in this issue, but unfortunately I won't have
much time for it. I'll let you know if I get to something.
I've found out what the problem is: When the Phong class tries to
generate a shader code block ( Phong::getCodeBlock() ), if the material
was actually
Hi Javier,
In the end, the fact that the shader generation code in phong.cpp was
trying to access a plug that didn't exist for a blinn material wasn't
the cause of the crash (the code is well guarded so it just returns an
empty plug). Plus, that plug is never used anyways (the
Hi J-S,
On Mon, May 9, 2011 at 5:15 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
In the end, the fact that the shader generation code in phong.cpp was trying
to access a plug that didn't exist for a blinn material wasn't the cause of
the crash (the code is well guarded so
Hi Javier,
Great! Thanks for the corrections. Submitted to svn/trunk.
Thanks!
Do you know of an easy way for CMake to create the folders (e.g.,
GLSL) inside the Visual Studio project source tree?
See the attached file. :-)
Hope this helps,
J-S
--
On Mon, May 9, 2011 at 9:58 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Do you know of an easy way for CMake to create the folders (e.g.,
GLSL) inside the Visual Studio project source tree?
See the attached file. :-)
Hope this helps,
You're my CMake hero! :-)
--
Hi J-S,
On Fri, May 6, 2011 at 10:45 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Good, pardon the negativism but it's a relief that you're seeing the crash
too now, at least it's not something totally trivial on my side :-)
I've gotten pretty far debugging this in release
Hi,
On Fri, May 6, 2011 at 3:24 AM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
This can actually be handled automatically with the right usage of FindOSG.
But I agree that it's not always obvious how to do that. When you start
writing tons of ifs for each configuration, it's
Hi Farshid,
OK. The different ways you mention above, are they all currently
supported by OSGExp? Meaning, the material name is exported? The
object properties field is exported as descriptions you say? (I
haven't gone through the code to OSGExp yet)
Yes, all the methods I described are
Just jumping into this thread, I admit that I haven't read it all the way
through, so hopefully this is relevant.
What I have done to support things like specular maps and bump maps in
models exported from Maya is to modify the dae loader found to support the
extra tags that are added to the
Hi Kim,
Just jumping into this thread, I admit that I haven't read it all the
way through, so hopefully this is relevant.
Of course, jump in whenever you want :-)
What I have done to support things like specular maps and bump maps in
models exported from Maya is to modify the dae loader
Hi J-S,
On Fri, May 6, 2011 at 3:49 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Here are the changes I have made to maya2osg.
1. I have modified the CMake config so it will use the OSG release and debug
versions correctly.
2. I made the Maya install directory
Hi all,
Here it is.
Argh, I didn't realize how big that was. I got a message from the list
saying it awaited moderator approval, you can safely refuse it, I'll
send it to Javier directly.
Sorry,
J-S
--
__
Jean-Sebastien Guay
Hi J-S,
On Fri, May 6, 2011 at 7:02 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
1. Named the osg::Light according to the MFnLight/MFnSpotLight name (i.e. if
the light's MatrixTransform is directionalLight1, then the osg::Light will
be directionalLightShape1)
2. Blinn
On Fri, May 6, 2011 at 7:41 PM, Javier Taibo javier.ta...@gmail.com wrote:
research to discover what computations does Maya for it. Now we have a
first approximation :) However, I don't know if it is working
^
Please,
Hi Javier,
Thank you for the changes. They are already submitted to svn/trunk.
Great, thanks. Can you please replace the filetexture.cpp by this one as
it's the behavior I think we want - if the Use As: field is anything
OTHER than Bump, don't convert bump2normal.
The Blinn shader
Hi Javier,
Great, thanks. Can you please replace the filetexture.cpp by this one as
it's the behavior I think we want - if the Use As: field is anything
OTHER than Bump, don't convert bump2normal.
Sorry I forgot the file, here it is.
BTW, it's fine to leave my e-mail in the AUTHORS file.
On Fri, May 6, 2011 at 8:29 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Hi Javier,
Great, thanks. Can you please replace the filetexture.cpp by this one as
it's the behavior I think we want - if the Use As: field is anything
OTHER than Bump, don't convert bump2normal.
Hi J-S,
jumping in to say hello, and sorry that I coudn't answer your post earlier. I'm
student, and as Javier mentioned my time is very limitted these days and for
the next two months. At Holiday time I contribute frequently, and I think this
won't cahnge too soon. So for now this is it,
Hi,
about the crash, I tried the file and it crashes on my system as well in
release mode. The polygon Export creates a Log nemad Maya2OSG_Write.log, stored
in the same directory of exported file. This might help a little. It exports
the mesh as geometry, but than creashes. I guss in Shading
On Fri, May 6, 2011 at 7:11 AM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Question then, where do I go in Max to set these kinds of tags? Can you
give me an example of what your artist would do to say that a given
object (or a given material) has a normal map?
Have you
Hi Javier,
Now bump mapping seems to be working fine again, btw...
Yes, I agree, when I run the plugin in Debug and get an output file as a
result it works well. Thanks.
And I must apologize, I absolutely lied to you in the other message.
Your scene crashes in Release mode. Just
Hi Farshid,
The problem I had with my own compiled version of OSGExp was indeed
caused by mismatched DLLs. The prebuilt version's installer copied the
OSG DLLs into the 3dsmax directory, as well as the Previewer.dll. When
compiling my own version, I was able to just have my own version of OSG
Hello again Farshid,
OK. The different ways you mention above, are they all currently
supported by OSGExp? Meaning, the material name is exported? The
object properties field is exported as descriptions you say? (I
haven't gone through the code to OSGExp yet)
Yes, all the
Hi J-S!
On Wed, May 4, 2011 at 10:27 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
maya2osg (Maya plugin)
---
As for maya2osg, it also seems active (last checkin Apr. 24th) and I was
able to compile it myself and use my compiled version without
Hi Javier,
OMG! X-D
How many minutes did you wait??? :)
About 5 ;-)
No seriously, about 5 hours, but it's fine, I didn't really expect a
reply that quick - it was meant as a joke, and I had other questions to
ask for the Max export plugin too so I started a thread about both
Hi J-S,
On Thu, May 5, 2011 at 10:25 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
No seriously, about 5 hours, but it's fine, I didn't really expect a reply
that quick - it was meant as a joke, and I had other questions to ask for
the Max export plugin too so I started a
Hi Javier,
I suppose you have a very short timeframe in justincaseidie.com :D
I didn't know about this, it's actually hilarious...
It will actually only be sent if you fail to log back in to the system
within the timeframe that you set, we're just sort of assuming that only
death would
Hi all,
As mentioned in a recent thread I'm looking at streamlining our content
creation pipeline these days. One thing I think would help is if we
could get models in a state where they're usable by our engine
immediately when they come out of the content creation tool. This would
require a
Hi Jean-Sébastien,
Have you tried the latest pre-built 64-bit osgmaxep installer? I've done
some limited testing with it on Max 2011 and 2012 and it seems to export
fine.
I don't check the sourceforge forums that often. I personally think
osgmaxexp questions would be better asked on this mailing
Hi Farshid,
Thanks for answering.
Have you tried the latest pre-built 64-bit osgmaxep installer? I've done
some limited testing with it on Max 2011 and 2012 and it seems to export
fine.
Yes, as I said it works fine. The problems arise when I compile the
plugin myself and try to use my
On Wed, May 4, 2011 at 4:55 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Yes, as I said it works fine. The problems arise when I compile the plugin
myself and try to use my compiled version in Max... It doesn't seem to work
the same as the pre-built one.
My question is how
Hi Farshid,
Sorry, I must have misread your original email. What is the exact error
message you are seeing? The installer will place the pre-built osg
binaries in the max application folder. It also adds the appropriate
osgexp install path to plugin.ini. So make sure to replace all the
Hi Jean-Sébastien,
OK. The different ways you mention above, are they all currently supported
by OSGExp? Meaning, the material name is exported? The object properties
field is exported as descriptions you say? (I haven't gone through the code
to OSGExp yet)
Yes, all the methods I described
73 matches
Mail list logo
