assimp-discussions — Discussions regarding the ASSIMP library.

Re: [Assimp-discussions] feature requests + data structure

[Thomas S. <th...@dr...>]

Hi again,

> > Maybe trifan and tristripes, too?
>That's a good point. In fact the VertexCache-Step does something 
>quite similar: it generates pseudo triangle strips with a full set 
>of indices per face. The problem is that you can't describe a large 
>model with just one strip. Implementing real triangle strips would 
>require a brute force algo to find the best possible combination 
>(and large meshes would be broken down in several smaller tristrip submeshes).
>This is really complicated, I would put it on the TODO list, but I 
>wouldn't implement it for the first release.

Since the dawn of indexed rendering triangle strips or fans are 
inferior. I don't see why outdated concepts should be supported. If 
you really need it, well... feel free to implement it. But in my 
opinion it's useless.

Bye, Thomas

Re: [Assimp-discussions] feature requests + data structure

[Alexander G. <ale...@gm...>]

Hi to everyone,

> Concerning the data format:
>
>   
>> >assimp is very similar to fbx sdk. did you envisage the possibility to make
>> >you class structure more or less compatible with it? so that one application
>> >can access a large number of file with a single source code? fbx is well know,
>> >really spread and it could be an advantage to be compatible.
>>     
>
> Haven't had a look at the data structure, yet, so I don't know how 
> similar the structures actually are.  Personally, I'd like to avoid 
> rewriting our data structures - there's quite a bit of work 
> associated with this change in all the loaders, and then some more in 
> all the projects using the lib already. If the fbx is structure is 
> convincingly better, then ok. But if it's just similar, it's enough 
> to add fbx support to Assimp as a simple loader class. The aim "read 
> many formats with a single source code" is also achieved.
>   
Agreed. FBX is not an open standard, thus we won't spend any time rewriting 
our data structures to be compatible with it. I personally like our data structure, 
it is easy to maintain and port.


>> >Do you plan to create export procedures too?
>
> No. At least not from my side. Writing all the writer classes might 
> be actually easier then writing the  reader classes, but you'd end up 
> with a lot of bug reports "program x can't read file in format y 
> written by Assimp". I'd say we better avoid this. If someone really 
> wants, he/she is free to open a branch and start coding.
Agreed. It should not be forgotten that we're writing assimp for our personal purposes,
 too. I don't need to write files :-)

> what lightwave (lwo) format are you supporting ?
Supported are LWOB (old format) and LWO2 (new format). If you want full LWO support, use the current post-beta development version in the SVN. However, I'm still working on this loader. There are some minor problems remaining, but I'd highly appreciate you to test it and give feedback.


> Maybe trifan and tristripes, too?
That's a good point. In fact the VertexCache-Step does something quite similar: it generates pseudo triangle strips with a full set of indices per face. The problem is that you can't describe a large model with just one strip. Implementing real triangle strips would require a brute force algo to find the best possible combination (and large meshes would be broken down in several smaller tristrip submeshes).
This is really complicated, I would put it on the TODO list, but I wouldn't implement it for the first release.


> We will not change the "default" behaviour of the beta stuff, because 
> this is just a optional way to provice primitives. So I cannot detect 
> any major issues with this.
Yes, as long as the TriangulateStep is specified the behaviour would be exactly as in the beta and lines and points will be filtered out.

I'll implement that, but it will take a while as there are many other places in assimp I'd like to rework/refactor/rewrite/improve/debug ...

Regards,
Alex

Re: [Assimp-discussions] Some feature requests

[Thomas S. <th...@dr...>]

Hey there,

Concerning the data format:

>assimp is very similar to fbx sdk. did you envisage the possibility to make
>you class structure more or less compatible with it? so that one application
>can access a large number of file with a single source code? fbx is well know,
>really spread and it could be an advantage to be compatible.

Haven't had a look at the data structure, yet, so I don't know how 
similar the structures actually are.  Personally, I'd like to avoid 
rewriting our data structures - there's quite a bit of work 
associated with this change in all the loaders, and then some more in 
all the projects using the lib already. If the fbx is structure is 
convincingly better, then ok. But if it's just similar, it's enough 
to add fbx support to Assimp as a simple loader class. The aim "read 
many formats with a single source code" is also achieved.

>Do you plan to create export procedures too?

No. At least not from my side. Writing all the writer classes might 
be actually easier then writing the  reader classes, but you'd end up 
with a lot of bug reports "program x can't read file in format y 
written by Assimp". I'd say we better avoid this. If someone really 
wants, he/she is free to open a branch and start coding.

>what lightwave (lwo) format are you supporting ?

Erm... can't tell. Who did the lwo loader?

Have fun.

Bye, Thomas 

[Assimp-discussions] Some feature requests

[kim k. <kim...@go...>]

Hi ML,

we got some feature requests:

Hi,

I am the developer of Albatross3d
(www.albatross3d.com<http://service.gmx.net/de/cgi/derefer?TYPE=3&DEST=http%3A%2F%2Fwww.albatross3d.com>)
a fee 3d modeling and
animation program. I will probably add assimp import capabilities to my
program. I do have a few questions/comments:
assimp is very similar to fbx sdk. did you envisage the possibility to make
you class structure more or less compatible with it? so that one application
can access a large number of file with a single source code? fbx is well
know,
really spread and it could be an advantage to be compatible.
Do you plan to create export procedures too?
what lightwave (lwo) format are you supporting ?

Nice work,

Pierre


So lets start the discussion :-).

With best regards,

Kimmi

Re: [Assimp-discussions] Proposal for a small data structure addition

[kim k. <kim...@go...>]

Hi ML,


> We've had this topic already 2 months ago, it's regarding point and line
> primitives.

I do remember :-\.


>
>
> Suggestion:
> * add bitmask constants for the four primitive types: tri, poly, point,
> line


Maybe trifan and tristripes, too?


>
> * add a member mPrimitiveTypes to aiMesh, contains a bitwise combination

of these constants

I do agree.

>
> * loaders don't need to set this value. if == 0, an additional
> "anonymous" post-process step (no public flag, always active) determines
> the primitive types for each mesh automatically.
> * add another step splitting meshes with different primitive types into
> submeshes. this step could also handle degenerated triangles (triangles
> with one or two unique vertex positions).
>

I do agree, this seem to be a way to deal with this kind of stuff.


>
> +
> * Points and lines would be supported. Rarely needed, but if one needs
> it in his application and assimp doesn't support it, the lib would be
> useless for him.
> * Loaders wouldn't need to filter out points and lines
> * Possible optimizations in the Triangulate-Step
> * Several other steps could be optimized, too. e.g. GenNormals
>

In my opinion this is a nice idea.


>
> -
> * Extra code for nearly every post-process step
> * Two additional steps to be implemented
> * Not sure whether it would really be useful
>
> Opinions? Comments?
> I would implement it, but only if the suggested changes find a majority.
>

We will not change the "default" behaviour of the beta stuff, because this
is just a optional way to provice primitives. So I cannot detect any major
issues with this.

With best regards,

kimmi

[Assimp-discussions] Proposal for a small data structure addition

[Alexander G. <ale...@gm...>]

Hi,

We've had this topic already 2 months ago, it's regarding point and line 
primitives.

Suggestion:
* add bitmask constants for the four primitive types: tri, poly, point, line
* add a member mPrimitiveTypes to aiMesh, contains a bitwise combination 
of these constants
* loaders don't need to set this value. if == 0, an additional 
"anonymous" post-process step (no public flag, always active) determines 
the primitive types for each mesh automatically.
* add another step splitting meshes with different primitive types into 
submeshes. this step could also handle degenerated triangles (triangles 
with one or two unique vertex positions).

+
* Points and lines would be supported. Rarely needed, but if one needs 
it in his application and assimp doesn't support it, the lib would be 
useless for him.
* Loaders wouldn't need to filter out points and lines
* Possible optimizations in the Triangulate-Step
* Several other steps could be optimized, too. e.g. GenNormals

-
* Extra code for nearly every post-process step
* Two additional steps to be implemented
* Not sure whether it would really be useful

Opinions? Comments?
I would implement it, but only if the suggested changes find a majority.

Alex

Re: [Assimp-discussions] English

[Alexander G. <ale...@gm...>]

> It seems to work, what do you think about an englich ML. So we can 
> avoid language issues :-).
>
> Kimmi
>

Ok, that's an argument, especially as SF.net is in english, too. So the 
"test" mail was hopefully the last german word here :-)

Re: [Assimp-discussions] Test

[kim k. <kim...@go...>]

It seems to work, what do you think about an englich ML. So we can avoid
language issues :-).

Kimmi

On Fri, Aug 15, 2008 at 12:32 PM, Alexander Gessler <
ale...@gm...> wrote:

> Nur ein kleiner Funktionstest, das ML-Prinzip ist mir nahezu neu  :-)
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Assimp-discussions mailing list
> Ass...@li...
> https://lists.sourceforge.net/lists/listinfo/assimp-discussions
>

[Assimp-discussions] Test

[Alexander G. <ale...@gm...>]

Nur ein kleiner Funktionstest, das ML-Prinzip ist mir nahezu neu  :-)