Yeah, but monogame is not the best reference to validate a model has been exported “ok”, as it does not load models as well as xna.
It is if what you care about is loading it in your MG game. It’s up to the animator to figure out what export options work, etc.
But I think you want to make some other point. It wasn’t about the viewer in the first place.
1 Like
I was wondering why many devs make their own validator for models, when monogame is not the reference. Maybe a lot of work spent when only monogame needs to be fixed/improved. But I understand it allows to say if a model will work or not with the needs of a particular game.
If every one creates its viewer, isn’t it because monogame(/assimp?) does not import models properly. Just asking.
If you can make that effect move between 3D points, say around a 3D model/scene, not so useless after all… [Gif 1]
Not really. FBX is a complex and very flexible format and not 2 programs implement it 100%. Every 3D tool exports differently and usually comes with a lot of options. It’s about finding the right combination.
The viewer saved us time, because we no longer had to move files back and forth, test them by rebuilding the whole project, etc.
BTW, my viewer was written on XNA! for my second project/game. Long before I knew that MG existed.
1 Like
Nice ! it’s a blur process or bokeh sprite? if bokeh sprite, how to do without Geometry shader?
it’s sprites / textures, I just draw quads (all of them in one pass though)
1 Like
how you detect which area to draw?
it’s not depth of field, it’s just a blur on an image, i draw on the complete image.
BUT
I could probably just use it for DOF, if I make the quad size dependent on depth and transform their size in the vertex buffer (similar to basic GPU particles). Unaffected quads have no pixels covered then.
I’ve build a very very basic particle simulation, similar to what I did with the grass for Bounty Road
The idea is to have each particle represented by a pixel in a render target (in the grass example this is not the case!) and solve spring equations for each pixel in this rendertarget.
In the image above i used 128x80 particles, so that’s the size of the rendertarget, too.
I need to have 2 of the rendertargets so they can read from each other. The active rendertarget is switched each frame for this reason. Obviously this is a limitation of using pixel shaders, but I’m fine with that.
The simulation runs at ~2500fps, but I think the limiting factor is something else at that point.
For what it’s worth it still runs with 500 fps with 1280x800 (over a million) particles. At that point I have massive overdraw though, so that’s a thing to consider.
3 Likes
Ooh, that’s cool! I could imagine just that system as a base for a game, looking at that gif 
1 Like
yeah, it’s pretty neat
Here it is with a million small particles that map to an image
4 Likes
This reminds me of something for random maze generation… forgot the name…
Contributing to this thread: GeonBit alpha first demo
This is a hobby game engine I’m working on with MonoGame. Its based on the Entity-Component-System model and provide all the basics needed to write a basic 3d game.
The demo in the vid is a “game” made with GeonBit, with approx 600 lines of game-logic code (eg code that is not part of GeonBit), which include the MonoGame ‘Game’ class + few custom components.
More updates will follow, depending on my progress speed.
3 Likes
Cool! The MG community needs more 3D IMO 
1 Like
I’ve written down a lot of stuff about recent work
4 Likes
an overview of the current state of the deferred engine, which you can download (source) from github
5 Likes
What are the tiles, that are visible for a moment at 0:02? Does rotation work with the gizmo? I have it implemented, but I must have a bug somewhere, because when rotating suddenly the object that is modified by the gizmo gets also scaled and deformed… May be an rounding issue 
Are you talking about my deferred engine?
what tiles? You mean the selection overlay?
