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
Hi Farshid,
I just added the support for normal map details in the description
string. The format is the following:
Normal
The method field can be one of the following strings:
Tangent
Local XYZ
Screen
World
Try it out and let me know if there are any issues.
I tried this, and I notic
Hi Farshid,
Just tried and it behaves as you described, so looks fine. I still haven't had
the time to do real tests on the shader side but I don't see any issues for
that, so I'd say the exporter now is really great for me.
Luca
--
Read this topic online here:
http://forum.open
Hi Luca,
On Thu, May 19, 2011 at 11:59 PM, Luca Vezzadini
wrote:
>
> 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
The method field can be one of the following strings:
Tangent
Farshid Lashkari wrote:
> Normal
> 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 Luca,
On Thu, May 19, 2011 at 12:59 AM, Luca Vezzadini
wrote:
>
> 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, tryi
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
http://www.cm-l
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
On Wed, May 18, 2011 at 1:06 PM, Luca Vezzadini wrote:
>
> 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. Is that
> right?
T
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 f
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 images\bball_normal
Hi Luca,
On Wed, May 18, 2011 at 8:02 AM, Luca Vezzadini wrote:
>
> 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
> straightforward to pa
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 suggesti
Hi Luca,
On Wed, May 18, 2011 at 3:24 AM, Luca Vezzadini wrote:
>
> 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 seems to include also
> t
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 t
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 appl
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 wa
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 mater
Hi Luca, Jean-Sébastien
On Tue, May 17, 2011 at 12:46 PM, Luca Vezzadini
wrote:
>
> 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 descripti
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 ma
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
osg
Hi Luca,
On Tue, May 17, 2011 at 6:12 AM, Luca Vezzadini wrote:
>
> 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?...
>
You are absolutely rig
Hi Luca,
On Tue, May 17, 2011 at 4:29 AM, Luca Vezzadini wrote:
>
> 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 channel, you first create
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 Stat
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 spe
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,
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 i
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
in
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,
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
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 have
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 should
Hi Luca,
On Mon, May 16, 2011 at 3:39 PM, Luca Vezzadini wrote:
>
> 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 so, we could have
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 a
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 o
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 assig
Hi Luca,
On Mon, May 16, 2011 at 1:57 PM, Luca Vezzadini wrote:
>
> 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 choose which strategy
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 4:44 AM, Luca Vezzadini wrote:
>
> 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 email from a few days
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
On Mon, May 9, 2011 at 9:58 PM, Jean-Sébastien Guay
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! :-)
--
Javier Taibo
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
--
___
Hi J-S,
On Mon, May 9, 2011 at 5:15 PM, Jean-Sébastien Guay
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 it just returns an empty plu
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
gl_FrontMateria
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 a
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 J-S,
On Fri, May 6, 2011 at 10:45 PM, Jean-Sébastien Guay
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 with debug symbols. First
>
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 test
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?
>>
>
> H
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 st
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, I'l
On Fri, May 6, 2011 at 8:29 PM, Jean-Sébastien Guay
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.
>
> Sorry I forgot the file,
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.
J-S
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 w
On Fri, May 6, 2011 at 7:41 PM, Javier Taibo 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, ignore this line. It
Hi J-S,
On Fri, May 6, 2011 at 7:02 PM, Jean-Sébastien Guay
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 materials will be shaded lik
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 Guayjean-seba
Hi J-S,
On Fri, May 6, 2011 at 3:49 PM, Jean-Sébastien Guay
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 user-visible because it might not be
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 foun
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
tags that are added to the Collada fi
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 suppor
Hi,
On Fri, May 6, 2011 at 3:24 AM, Jean-Sébastien Guay
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 a clear sign that you're
> no
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 J-S,
On Thu, May 5, 2011 at 10:25 PM, Jean-Sébastien Guay
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 thread about both plugins.
I
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 pl
Hi J-S!
On Wed, May 4, 2011 at 10:27 PM, Jean-Sébastien Guay
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 any problems.
> But again the
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 metho
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
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 describe
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
installed
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
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 compil
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 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
74 matches
Mail list logo
