[StarnickKeymaster]

Nope. That section talks more about a few classes that are utilities one can use when writing your own loaders. AssimpNet is just a wrapper for importing/exporting from the already preconfigured loaders in the library and is not really intended for extending Assimp functionality. If you want to add a new one you’d have to write it in C++, recompile the native library, then use that DLL with AssimpNet.

[StarnickKeymaster]

At work we use P4 which is very SVN like. I do find the visual studio integration for Git (at least the official one that runs off the TF browser) to be a bit bare bones but it seems good enough.  I ended up creating the repository using BitBucket’s desktop UI (SourceTree) which is very snazzy. The VS plugin is good enough for visual cues adding/modifying files and then pushing/pulling.

 

Well anyways, enjoy. Be sure to report any bugs on the issue tracker (I know there must be a lot lurking in the math library). If something looks incomplete though, it probably is. Not quite yet at the point where everything will work out of the box like XNA with minimal effort.

[StarnickKeymaster]

A patch would be good, preferably posted on the issue tracker. Although it looks like someone else has posted some patch files for Mac. I’ll have to review.

 

Thanks!

[StarnickKeymaster]

=>

https://bitbucket.org/Starnick/tesla3d

Went with BitBucket. Excuse the mess and some key incompleteness.

[StarnickKeymaster]

Good timing. Last two days I’ve been evaluating whether or not I’m going to switch off of Googlecode since that service kind has burned me with disabling downloads. In that potential move I’ve been learning about Git and have been deciding whether to go with BitBucket or GitHub. Right now leaning on BitBucket, and I’m kind of itching to actually get the v2 codebase out there in the wild. It’s been more than “far too long”.

The grand plan of finishing the port from the old engine codebase never really fully materialized due to time constraints. The last few months in what spare time I do have has been spent on greatly expanding the size and scope of the Bounding Volume API (following an effort to greatly expand the size and scope of the Math library last fall), and that led to an effort on geometry generation for visualization. The old shapes API was hard wired with how meshes were designed and also didn’t support a lot of shapes or advanced features like tessellation for most shapes. The v2 codebase now supports a generic “Geometry Generator” API that treats each shape just as a provider to an algorithm to create the primitives and returning data to be used elsewhere, rather than being a container for the data. Also this new shapes API has a better focus on tessellation (no more hardcoded low-res teapots…)

And in addition to generators, also am working on primitive batching – E.g. DirectXTK’s “PrimitiveBatch” that is similar to XNA’s SpriteBatch but functions like the old DrawUserPrimitives. So the idea is being able to support a wide amount of dynamic geometry drawing without being tied to specific mesh implementations. We’re talking about boxes, spheres, capsules, pyramids, planes, torii, cylinders (robust enough to make cones, tetrahedrons, and octahedrons), Utah teapots, and soon geospheres.

At this point v2 of the engine is more Math library than graphics library at the moment. That kind of has been the style of development really in the last year and a half. Focus on a lot of little different modules on topics that I find interesting, such as general math, collision and intersection, geometry, etc. The engine is mostly a conglomerate of small libraries at this point loosely tied together. I prefer it that way, since while all this work is purely for myself, anyone who may use it probably will maximize their use of the engine as they can just take and use the portions they need.

• This reply was modified 9 years, 7 months ago by  Starnick.
• This reply was modified 9 years, 7 months ago by  Starnick.

[StarnickKeymaster]

You really should. The collada importer in Assimp seems to support the format pretty well. If you’re only interested in running the library on Linux, I would imagine the only real work you’ll need to do is deal with the project files. Keep in mind the library is AnyCPU and the unmanaged library is loaded dynamically so you probably don’t have to make any modifications to the codebase itself. You’ll need to recompile Assimp for Linux though, and there probably are a lot of resources out there to compile with Mono in VS or just port the project files to MonoDevelop. Remember to run the post-process interop program to patch the AssimpNet assembly with your custom compilation.

[StarnickKeymaster]

The library is designed for cross-platform compatibility through Mono, but I only provide .NET support out of the box. I have had users who have gotten the library onto mac/linux and even Android devices so the code is/should be compatible with Mono. Keep in mind with mobile devices though: the library was always imagined to be for desktop usage, e.g. offline processing in a content pipeline for models.

If you drill into the AssimpLibrary.cs source the interop layer for loading the unmanaged component will have different implementations depending on runtime and we do ship with a linux implementation that loads .so rather than .dll out of the box. That was added a bit ago to aid in getting users started with a non-Windows platform. So long story short is that the code should be compatible and run well, but you just will have to find your own way in compiling it in another IDE than Visual Studio or for another target platform. None of the users who have done work in getting the library compiled for another target platform ever donated code back. I generally stick with Windows platforms and Visual Studio (although I see better and better support coming for VS with compiling with Mono and Xamarin), so development on the library is heavily influenced by where I’m taking my other projects that rely on the library.

[StarnickKeymaster]

Well, I work on CAD products. The product line already is out there in the wild (just not the part I work on, but it’s a large technology platform). Here’s a favorite youtube video of mine:

 

 

 

Edit – Nice! The forum automatically embeds youtube links. Didn’t even know it did that.

• This reply was modified 10 years, 2 months ago by  Starnick.

[StarnickKeymaster]

Hey Abe!

 
Yeah…the fall milestone kind of slipped, didn’t it? I wish I could say I have been in traction for the last five months and haven’t been able to move at all…but I can’t lol. Just been busy with work and life. At work we’ll be shipping the product that I’ve been working on for almost two years this month, so yeah it’s been busy.

Everything else just slipped, even AssimpNet. I should really just throw what I have up on the SVN rather than think I’m going to have this grandoise revamp unveiling. Not to mention you’ll probably be the only one there! heh

• This reply was modified 10 years, 2 months ago by  Starnick.
• This reply was modified 10 years, 2 months ago by  Starnick.

[StarnickKeymaster]

FYI, I split the topic into its own thread.

I keep every release tagged in the SVN, so reverting to a release to recompile should be fairly painless. This isn’t the first issue with Unity that has been reported, but some users have been successful in getting the library up and running on that platform. I’m not familiar with that exception, so I can’t be much help in diagnosing how to integrate into Unity I’m afraid, as I don’t use it. What I do know that has been reported is there will be issues with later versions of AssimpNet (post-v 3.0 after the P/Invoke went to a dynamic loading scheme rather than static DLLImports) with iOS as its a platform limitation. Something with iOS only allowing for static linking. I’m not sure if this is the cause or if there are other issues at play.

But let’s take a step back for a moment, Assimp is squarely a “tool pipeline” library, which generally means the target is the developer’s PC. There are some exceptions of course (e.g. a model viewer for android), but that’s largely the intended audience. A la the XNA Framework Content Pipeline is not intended for consumption by Xbox 360 or Windows phone. It is quite possible to use the library to convert to whatever internal format you use off-line.

Here’s a superb write up about the Assimp data structure (geared for animation, but I’m sure that’s where you probably will be heading with Unity as it has support for that):

http://gamedev.stackexchange.com/questions/26382/i-cant-figure-out-how-to-animate-my-loaded-model-with-assimp

And I suggest the official Assimp docs as well. The managed scene structure is more or less a 1 to 1 mapping of it.

[StarnickKeymaster]

Hmm yes, I don’t yet have a build procedure for Mono yet (I’m under the impression that GetHRForLastWin32Error is there, but just not implemented, so even on a Windows desktop you’ll run into an exception there?)

The location of the unmanaged DLL (Assimp.dll) by default needs to be in the same directory as the managed one, but you can override this by passing a path to AssimpLibrary to where the unmanged DLL is located. It gets loaded dynamically, either implicitly by the AssimpContext  when first needed or explicitly by you.

The second error you’re running into is because during compilation the post-process AssimpNet.Interop.Generator is not being run. What is on the trunk is radically different than the last release. After the main project is compiled, the assembly is patched with IL generated by Mono.Cecil, which is included in the “libs” folder on the trunk. So if you’re not using the visual studio solution, you have to be aware of this two-step process to get AssimpNet compiled correctly.

InternalInterop is a static class full of stubs that get replaced by this generation process, functionality to support marshalling of data to/from unmanaged memory.

[StarnickKeymaster]

The trunk does (the current release in the downloads section is just windows). It’s somewhat untested/experimental at the moment, and you’ll have to re-compile the native Assimp library for those platforms. The refactoring was mostly geared for Linux (and since I haven’t heard bug reports from the brave souls who are using Linux, I assume its working – I still need to get around to verify that though). But that same implementation should work on MacOSX without too much effort.

This testing and verification at this point is what is holding back the next official release, so I welcome people to test

[StarnickKeymaster]

Yep, WPF support is something I also need to.

It’s one of those things that was a catalyst for development for v2. In the waning days of the the first engine’s development (last year!) I actually got this working for a forum poster…but it required some hacks to the D3D10 implementation. In v2, I want it to be a first class, out of the box feature.

[StarnickKeymaster]

It’s an unfinished task for the site. To the right of the nifty spaceship in the header there’s that blank area…I want to put RSS/Twitter social icon links there (genesis has defaults for one or the other, but not both at the same time, and the sizes clash a bit with the customized header). Just something that hasn’t been done yet. In the meantime, the RSS feed is:

http://www.tesla-engine.net/feed/

[StarnickKeymaster]

Hmmm, kind of but I wouldn’t really call it that. Actually just the other day I saw something about inlining IL with C#:

 

http://blogs.msdn.com/b/jmstall/archive/2005/02/21/377806.aspx

 

From the explanation, that tool is basically what the interop generator is doing…just more generically but with the same sort of limitations. However, you write the IL alongside your C# code (which is more like what you’re describing). Really at the end of the day, its all doing the same sort of process so I wouldn’t get too hung up on it.

 

 

[Author]

Posts