Ogre Meshy 1.6 (Mesh viewer, Windows Installer & Linux sup.)

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
Post Reply
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by dark_sylinc »

Cool thing you're working on the CMake script. That's an area I'm lacking of (nor cared too much)
tdev wrote:oh, and i reduced its frame-rate to 25 FPS. There is really no reason why it should run with vsync/60FPS IMHO.
I disagree. The needed frame rate is dependent on the animations the user is trying to achieve. For instance my meshes are currently running animations at 30 FPS, thus 25 is not enough. Otherwise I'll miss keyframes and won't spot glitches. Furthermore I need 60fps in case there are two key frames where interpolation fails miserably (i.e. a bone doing a full spin when rotating).
Ogre Meshy must adapt to the general uses that may be given, so VSync is a reasonable limit (usually 60hz).
Take in mind some hard core Ogre uses (probably non-game related) may use Meshes with animations running at 60FPS
tdev wrote: - FIX THE mouse drag rotation of objects: its very un-intuitive the way its implemented atm. The user needs a classic drag&drop feeling when rotating objects IMHO
Really? I think the exact opposite and was based on multiple viewer's behavior. I'm the one who designed though, so I'm biased and need other people's feedback.
Nevertheless, if you want to implement an alternate method, do it in such a way the user can select the behavior he prefers (which behavior would be saved in the user config).
tdev wrote:- add the 3d axis mesh in the lower bottom corner of the 3d screen: much better and more professional ;)
Again, "it depends". Depending what you're doing, the axis in the origin is more useful (for instance when using it as a comparison for bone orientation in an animation). In other situations the lower bottom corner is more useful (for example, when you want to have an orientation guide while manipulating the camera).
tdev wrote:- maybe add propertygrid to display mesh info. I find it much more compact and better organized (see my old viewer as example: http://www.ogre3d.org/forums/viewtopic. ... 25#p401959)
That's true but I'll also find it more cluttered and harder to go through.
The current way allows to see everything in one glance. Furthermore the property grid was designed for editing, which makes it harder to navigate with the arrow keys.
tdev wrote:- problem notification (like in eclipse) with errors and warnings and possible problem solution suggestions when clicking on it
That requires a lot of effort. Not just a one-time job. It requires constant maintenance. Since no one is getting paid, I don't think it's a good idea to implement something that will be broken in 1 and a half year.
tdev wrote:- global set-able include paths for resources
Edit (forgot to about this one): I haven't figured a way to do it cleanly. Every way I came up with results in big drawback somehow. If that's too important for an user he can create a shortcut:

Code: Select all

Ogre Meshy.exe "/r:C:\MyFolder\resources.cfg"
tdev wrote:- improved mesh information on the info tab
Edit (forgot to about this one): That's welcomed, extra info such as? (not being sarcastic, just curious)
tdev wrote:- highlighting selected submeshes/materials in the tree view in the 3d view
Yeah, that's in my TODO.
tdev wrote:- click on mesh and select appropriate geometry/material in the tree of the selected face?
Not sure if reasonable considering the feature above is implemented. It would be redundant, cause more HUD cluttering (currently the mouse is just for rotating, consider if it can do a lot of other stuff which was triggered accidentally and the user just wanted to rotate the model??)
tdev wrote:- add Pane to view Materials/Textures/UVMappings
That's nice but it's top down in my TODO list.
tdev wrote:- add importer/exporter function for other file formats, easy to integrate i guess.
- automatic mesh upgrade/downgrade via menu?
- LOD testing mode?
- automatic LOD generation? maybe use a better algorithm than what is implemented in Ogre itself ...
- material/shader testing? changing the material/shader variables via propertygrid on the fly?
- plugin concept: would be awesome to use this to preview and edit the Procedural generated objects on the fly (see my signature)
All nice ideas I've thought too. However: Viewer != Editor. Seems many features that would do well in a separate project. OgreMeshy is a viewer, a quick first-timer approach that works well and does what it's needed. If it needs a manual, we're doing it wrong. Basically Jacmoe resumed it in the same link you've provided.

I've been having my ideas of making an IDE for Ogre content creation where you can load resources in projects, drag & drop textures into materials, have a general view, open the material scripts with syntax highlighting and error highlighting, etc, etc. Heck! I've even be so mad at GIMP's slow progression that sometimes I just want to start my own editor (I know I can do it). But I have time for none of those. I'm working on something else. Such projects require tremendous maintenance effort. May be if I succeed with my personal entrepreneurships I'll start one of those.

I'm happy to see your enthusiasm, just be sure you understand the vision. It also looks like you could have a nice read to Apple's HID guidelines. Keep it bookmarked and be sure you come back at it and read again once in a while, just as I do. It's refreshing.

Cheers
Dark Sylinc
User avatar
toglia
Gnome
Posts: 336
Joined: Sat Dec 08, 2007 4:28 am
Location: Canada
x 7

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by toglia »

I like everybody's enthusiasm with Meshy! Meshy helped me a lot and I would like the project stayed alive for good.

I would also like to add some thoughts.

First, I'm also in favor of leaving Meshy as a viewer. As simple as that. Ogre needs an official (or almost) 100% working one.

Secondly I would also like that Meshy used some DCVS repository. For starters you would stop updating Meshy's link on the wiki. I ended up downloading an old version cause the link in the wiki was outdated by that time...

And here I post some of my personal *viewer* TO-DOS/Feature Requests:
Switchable camera navigation systems.
One of the first things I changed from Meshy was the camera navigation system. Personally I've been using Maya for years now and their three-button camera navigation is almost second nature to me. It would be cool to have a preference window to choose the navigation you like. (Maya, Max, etc)

F key for camera pivot focus.
In Maya (again) pressing the F key will change the camera's pivot point to the component your selecting (it will zoom a little too). This is EXTREMELY useful when working with non centered meshes like Ogre's Jaiqua mesh. This is particularly helpful cause in my case I use Meshy to look for shader or mesh flaws, so I end up looking closely to complex regions of the mesh, checking how the light reflects, bad seems, normal irregularities, etc, and Maya's "focus" command is just great in those situations. Can be developed using rayscasting¿?

By the way, in linux the color picker had some wierd issues I fixed:

Code: Select all

retVal.setAsABGR( colourDlg.GetColourData().GetColour().GetPixel() ); //This didn't work good on linux
I changed to:

Code: Select all

retVal = Ogre::ColourValue(
			float(colourDlg.GetColourData().GetColour().Red())/255.0,
			float(colourDlg.GetColourData().GetColour().Green())/255.0,
			float(colourDlg.GetColourData().GetColour().Blue())/255.0,
			1
		);
That basically all I would like in a viewer.
Last edited by toglia on Sat Aug 13, 2011 3:07 am, edited 3 times in total.
User avatar
toglia
Gnome
Posts: 336
Joined: Sat Dec 08, 2007 4:28 am
Location: Canada
x 7

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by toglia »

The other thing I did which I found pretty obvious was to load the latest resource (if available) automatically when loading a mesh. So doing a quick Ctrol-O would give you a materialized mesh. I can suspect the resources file location would change very little during a project, so its pretty logical one would set it once. I know there's the F8, but pressing it every-time was getting annoying...
iFire
Gnoblar
Posts: 24
Joined: Mon Sep 26, 2005 6:39 am
x 1

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by iFire »

If you want this to be the official viewer for Ogre3d shouldn't the license be the same as Ogre before it's too hard to change?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by dark_sylinc »

Thanks for all the brainstorming guys!
toglia wrote:Secondly I would also like that Meshy used some DCVS repository. For starters you would stop updating Meshy's link on the wiki. I ended up downloading an old version cause the link in the wiki was outdated by that time...
**Sigh** Why is it just me??????? :cry:
toglia wrote: Switchable camera navigation systems.
One of the first things I changed from Meshy was the camera navigation system. Personally I've been using Maya for years now and their three-button camera navigation is almost second nature to me. It would be cool to have a preference window to choose the navigation you like. (Maya, Max, etc)

F key for camera pivot focus.
In Maya (again) pressing the F key will change the camera's pivot point to the component your selecting (it will zoom a little too). This is EXTREMELY useful when working with non centered meshes like Ogre's Jaiqua mesh. This is particularly helpful cause in my case I use Meshy to look for shader or mesh flaws, so I end up looking closely to complex regions of the mesh, checking how the light reflects, bad seems, normal irregularities, etc, and Maya's "focus" command is just great in those situations. Can be developed using rayscasting¿?
Been a while since last time I opened 3DS Max (a while = 3 years). Refresh navigation style please? If I recall correctly Middle mouse moved camera, right?

You have Alt+1..3 for camera. Since many users should be used to the F camera I don't see why not using also F key. However... what do you mean by pivot point? (I know what a pivot point means) I mean... the Jaquia mesh IIRC correctly moves in animation, therefore the bounding box's center isn't an accurate method for retrieving the object's "center". May be you mean "follow a specific bone" function?
toglia wrote: By the way, in linux the color picker had some wierd issues I fixed:
Thanks! Must've been some ARGB <-> BGRA thing or just not working GetPixel() in Linux.

Cheers
Dark Sylinc
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by dark_sylinc »

iFire wrote:If you want this to be the official viewer for Ogre3d shouldn't the license be the same as Ogre before it's too hard to change?
I'm open for opinions, but there are vital differences in it. Ogre 3D has a permisive license because the most important element is the code itself, and linking to it (and adapting the code to it's needs). Furthermore these custom changes may be used in the final code from the whole application (typically, a game). The modified code 99% of times must ship with the game.

A tool instead, it's most important element is it's functionality instead. Furthermore, the GPL requires that code changes must go together with the binaries (or be at a different place with easy access). If a Game Studio for example modifies Meshy to adjust to his own needs; they don't need to publish these code changes as long as they don't distribute the modified binary (aka. they keep it for themselves).
Rarely a tool is shipped with the game, unless it's a modding tool. But if you're releasing a modding tool, you won't have much problem releasing the source code changes anyway.
This way, the GPL prevents someone else modifying two bits about Meshy and then competing with us.

I don't know where did he wrote it, but even Sinbad told me that GPL was more suited for an Ogre tool than MIT license.
User avatar
toglia
Gnome
Posts: 336
Joined: Sat Dec 08, 2007 4:28 am
Location: Canada
x 7

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by toglia »

dark_sylinc wrote: However... what do you mean by pivot point? (I know what a pivot point means) I mean... the Jaquia mesh IIRC correctly moves in animation, therefore the bounding box's center isn't an accurate method for retrieving the object's "center".
I see. Didn't notice the jaiqua centered on certain animations. Anyway, like you say, the bounding box is not very accurate. What I'm saying is to manually set the camera's pivot point on the raycast hit, this would also zoom coherently, allowing to pivot correctly anywhere you wanted.

Maya's navigation:
Rotate/Orbit camera = Left mouse;
Pan camera = Middle mouse.
Dolly/Zoom = Right mouse. Note that in maya lowering the cursor is actually zooming more (like pulling the object).

3dmax navigation:
Rotate/Orbit camera = Alt+middle mouse.
Pan camera = Middle mouse.
Dolly/Zoom = Ctrl+Alt+middle mouse. Don't remember if its inverted...

And I think that the F key in 3ds max is in fact the Z key.
Last edited by toglia on Sat Aug 13, 2011 4:54 am, edited 1 time in total.
User avatar
toglia
Gnome
Posts: 336
Joined: Sat Dec 08, 2007 4:28 am
Location: Canada
x 7

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by toglia »

Blender navigation:
Rotate/Orbit camera = middle mouse. (Weird free rotation)
Pan camera = Shift+middle mouse.
Dolly/Zoom = Ctrl+middle mouse.
User avatar
toglia
Gnome
Posts: 336
Joined: Sat Dec 08, 2007 4:28 am
Location: Canada
x 7

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by toglia »

dark_sylinc wrote:As much as I like the DCVS concept, unlike Sinbad I consider current tools to be still in Stone age. I'm only using Mercurial due to Ogre using it.
On my personal proyects I use GIt/Github and SmartGit (Git GUI). Don't have to think much about it, everything just works as I need it...

dark_sylinc wrote:May be SourceTree is the future (I haven't tried it) as we share the same view and worries (the difference lies in that Steve finds the current state as "acceptable" while I don't), but it's Mac Only.
You haven't tried it but think that the current version is unacceptable. Just sounds odd. :P
User avatar
merlinblack
Goblin
Posts: 223
Joined: Thu Mar 15, 2007 10:05 am
Location: Sydney, Australia
x 7
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by merlinblack »

The usual rotation in Blender annoys me, I always switch it to 'Turntable' mode in the settings. One thing I really like in Blender is using the number pad for the views...

7 - Top


1 - Front 3 - Left side

Holding down shift gives you bottom, back and right.

4,6,8 and 2 work like arrow keys, spinning the view around the pivot point and 5 toggles between orthographic and perspective.

Can't remember what 9 does of the top of my head.. :?

I haven't used Maya but I like the sound of 'F for focus mode.

As for source control I use Git/Github for my personal work and Git and a Gitosis server at work with a team of 4. Works well.
"He'd never realized that, deep down inside, what he really wanted to do was make things go splat."
Terry Pratchett, Reaper Man
Image
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by dark_sylinc »

@tdev:
Ok, I'm just left with NSIS installer, CMake and Linux madness.
I've adapted your code changes, with a few differences:
  1. The way you were getting "User/AppData" was too unsafe. No error handling whatsoever and doesn't work on some language locales (i.e. Russian). Fixed. On catastrophic failure it defaults to the current directory (i.e. the old behavior). It may still crash if there's no write access to the current dir.
  2. A few unsafe implementations here and there fixed.
  3. Slight changes to formatBytes() (removed unnecessary cast and variables) plus it's now private.
  4. Fixed some messages not being coloured correctly.
  5. Log window now scrolls correctly again.
  6. Zooming in with the mouse right button would sky rocket. Fixed.
  7. Toolbar is kept on the top, for the time being (I've just not decided yet)
As for the messages not being coloured correctly, it was because you were calling SetDefaultStyle then createLogWindow which somehow affects the style if the window was hidden (but would work correctly if the log window was being shown). Calling createLogWindow then SetDefaultStyle fixed it.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by dark_sylinc »

toglia wrote:
dark_sylinc wrote:May be SourceTree is the future (I haven't tried it) as we share the same view and worries (the difference lies in that Steve finds the current state as "acceptable" while I don't), but it's Mac Only.
You haven't tried it but think that the current version is unacceptable. Just sounds odd. :P
Uh oh! The message got missinterpreted! Sourcetree is an app developed by Steve. And everyone speaks wonders of it. My guess is that his app is most likely exactly what would leave Git/Hg out of stoneage... but I can't use it if it's Mac-only
Regarding the other tools out there (i.e. TortoiseHg), Steve finds them acceptable, I don't.
toglia wrote:On my personal proyects I use GIt/Github and SmartGit (Git GUI). Don't have to think much about it, everything just works as I need it...
That's the problem. I don't "just use" SVN; I use a lot of it's features and most importantly TortoiseSVN is very productive.
Trying to find changes ordered via different criteria, searching version history only related to a specific file or folder is a nightmare in Mercurial/Git tools. I'm not blaming Mercurial or Git, but rather the HIDs around them. As an analogy, it's like having a great library like Ogre without a single decent mesh viewer :)

Thanks for the Maya & Max explanation. I know how Blender works because I use it on a daily basis. Actually hotkeys on the numpad isn't a bad idea.
I agree with merlinblack (awesome avatar BTW) though, the usual mouse rotation is annoying. You get used to it, but it's not optimal.

Will take it into consideration.
IIRC Ogre has a raycasting function which works up to triangle level. Once you get which triangles (I hope Ogre gives triangle index data) I can get which bones are affecting that point and then transform it during animation.

@toglia: Give me your full name (PM me or email me dark_sylinc [at] yahoo [dot] com [dot] ar) to be included in the credits. Gracias por los aportes, no sólo en código ;)

Edit:
Edit: Uninstall should ask to remove user config files.
yes, NSIS generation is very limited via CPack. I guess we are better writing our own NSIS installer later on.
May be not. I'm no CPack guru, but looks like CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS & CPACK_NSIS_CREATE_ICONS_EXTRA are exactly what's needed (got the info from here).
Vielen Dank für deine Hilfe ;)
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by jacmoe »

Did you try TortoiseHg ?
It's better than TortoiseSVN in my opinion. :)
thg log gives you the repository explorer from where you can access most of the functionality of Mercurial in a graphical way.
Of course, you can click on a file to show it's history.
After using that, I really can't bear to wait on SVN - it feels like swimming in syrup in comparison ..
But each to his own, I guess. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
tdev
Silver Sponsor
Silver Sponsor
Posts: 244
Joined: Thu Apr 12, 2007 9:21 pm
Location: Germany
x 14

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by tdev »

dark_sylinc wrote:
Edit: Uninstall should ask to remove user config files.
yes, NSIS generation is very limited via CPack. I guess we are better writing our own NSIS installer later on.
May be not. I'm no CPack guru, but looks like CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS & CPACK_NSIS_CREATE_ICONS_EXTRA are exactly what's needed (got the info from here).
Vielen Dank für deine Hilfe ;)
yes, i saw that as well, but please show me how you associate file types to the application ;)
i am currently using a custom NSIS extension for doing that in my app: http://nsis.sourceforge.net/File_Association
dark_sylinc wrote:
tdev wrote:oh, and i reduced its frame-rate to 25 FPS. There is really no reason why it should run with vsync/60FPS IMHO.
I disagree. The needed frame rate is dependent on the animations the user is trying to achieve. For instance my meshes are currently running animations at 30 FPS, thus 25 is not enough. Otherwise I'll miss keyframes and won't spot glitches. Furthermore I need 60fps in case there are two key frames where interpolation fails miserably (i.e. a bone doing a full spin when rotating).
Ogre Meshy must adapt to the general uses that may be given, so VSync is a reasonable limit (usually 60hz).
Take in mind some hard core Ogre uses (probably non-game related) may use Meshes with animations running at 60FPS
yes, the animations are the only reason why you would want to use 60FPS :)
90% of my use-cases are static meshes only: it completely makes no sense to draw more often than required. I guess you could pitch up the FPS if there are animations.
also, building a game engine to require a certain FPS is a serious design problem IMHO, just as side note ;)
dark_sylinc wrote:@tdev:
Ok, I'm just left with NSIS installer, CMake and Linux madness.
I've adapted your code changes, with a few differences:
  1. The way you were getting "User/AppData" was too unsafe. No error handling whatsoever and doesn't work on some language locales (i.e. Russian). Fixed. On catastrophic failure it defaults to the current directory (i.e. the old behavior). It may still crash if there's no write access to the current dir.
  2. A few unsafe implementations here and there fixed.
  3. Slight changes to formatBytes() (removed unnecessary cast and variables) plus it's now private.
  4. Fixed some messages not being coloured correctly.
  5. Log window now scrolls correctly again.
  6. Zooming in with the mouse right button would sky rocket. Fixed.
  7. Toolbar is kept on the top, for the time being (I've just not decided yet)
As for the messages not being coloured correctly, it was because you were calling SetDefaultStyle then createLogWindow which somehow affects the style if the window was hidden (but would work correctly if the log window was being shown). Calling createLogWindow then SetDefaultStyle fixed it.
can i get the source code? i want to see myself the unsafe parts, so i can learn from that.

i dont want to exchange huge discussions in here as we have different standpoints in some ways i guess. I think the best solution in this case is that i fork the project for myself and that you can merge back some code if you like it. Are you ok with that?
That way i can also merge back code from you and you can see the diff i applied.

@jacmoe: feeling the same way about SVN ;)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by dark_sylinc »

tdev wrote:
dark_sylinc wrote: May be not. I'm no CPack guru, but looks like CPACK_NSIS_EXTRA_UNINSTALL_COMMANDS & CPACK_NSIS_CREATE_ICONS_EXTRA are exactly what's needed (got the info from here).
Vielen Dank für deine Hilfe ;)
yes, i saw that as well, but please show me how you associate file types to the application ;)
i am currently using a custom NSIS extension for doing that in my app: http://nsis.sourceforge.net/File_Association
Hehe, I don't :oops:
It's in my TODO list. Mainly because unless you're experienced in it, it takes a lot of digging resources to do it right.
If that ext. can't be used in CPack (I hope it can...) we can write a small exe (or in Meshy, and use command line to register) that replicates that behavior in the script. Then from NSIS call the exe while installing (using CPACK_NSIS_EXTRA_INSTALL_COMMANDS)
Since I'm lazy I hope that extension can be used.

BTW: I do file association by double clicking a mesh file, then selecting Ogre Meshy and clicking to remember that association................
tdev wrote:yes, the animations are the only reason why you would want to use 60FPS :)
90% of my use-cases are static meshes only: it completely makes no sense to draw more often than required. I guess you could pitch up the FPS if there are animations.
That sounds reasonable (I wrote that comment before trying it), though I've ran it with the 25FPS cap and instead I got very jumpy framerate (jumping between 20-45 FPS) which was very annoying. I'm convinced the reason is in the timer (AFAIK, the only way to update a window at time intervals using wxWidgets), in Win32 that timer has poor resolution.
tdev wrote:also, building a game engine to require a certain FPS is a serious design problem IMHO, just as side note ;)
Actually, it's exactly the opposite. You want physics & logic to be fixed though, while interpolating in graphics and running as fast as you can (until you get VSync). Nevertheless if you use Ogre's animation data for physics or logic, you'll need them to run properly with fixed framerates (I clone Ogre's data to use in physics for motion extraction, for calculating joint points for my rigid body constraints in Havok, and to get the mesh shape information for complex objects, typically buildings).
dark_sylinc wrote:i dont want to exchange huge discussions in here as we have different standpoints in some ways i guess. I think the best solution in this case is that i fork the project for myself and that you can merge back some code if you like it. Are you ok with that?
That way i can also merge back code from you and you can see the diff i applied.
Sure, I'm just so convinced about SVN (I guess this is the time where I'm acting selfish)... I'll be uploading v1.3 sometime around this week (whether I choose SVN or Hg) then upload the changes (so we have two commits) and you can see the difference. Beware, I'm anticipating a busy week :roll:
BTW, no problem about forking the project, just make it more obvious it's a non official/fork release. Currently it looks like it's an official release (Because of the name and/or version number).

Cheers
Dark Sylinc
User avatar
tdev
Silver Sponsor
Silver Sponsor
Posts: 244
Joined: Thu Apr 12, 2007 9:21 pm
Location: Germany
x 14

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by tdev »

dark_sylinc wrote: It's in my TODO list. Mainly because unless you're experienced in it, it takes a lot of digging resources to do it right.
If that ext. can't be used in CPack (I hope it can...) we can write a small exe (or in Meshy, and use command line to register) that replicates that behavior in the script. Then from NSIS call the exe while installing (using CPACK_NSIS_EXTRA_INSTALL_COMMANDS)
Since I'm lazy I hope that extension can be used.
BTW: I do file association by double clicking a mesh file, then selecting Ogre Meshy and clicking to remember that association................
yes, something along this. Better way would be to be able to add custom script to certain sections in the resulting nullsoft script.
dark_sylinc wrote:
tdev wrote:yes, the animations are the only reason why you would want to use 60FPS :)
90% of my use-cases are static meshes only: it completely makes no sense to draw more often than required. I guess you could pitch up the FPS if there are animations.
That sounds reasonable (I wrote that comment before trying it), though I've ran it with the 25FPS cap and instead I got very jumpy framerate (jumping between 20-45 FPS) which was very annoying. I'm convinced the reason is in the timer (AFAIK, the only way to update a window at time intervals using wxWidgets), in Win32 that timer has poor resolution.
i think i know why: i saw that the windows event queue triggers updates and your timer at the same time. This will generate more paint events than you need and thus results in jumpy framerate as the windows events are getting in randomly.
i guess you can fix that by adding a minimum time before updating again .
dark_sylinc wrote:
tdev wrote:also, building a game engine to require a certain FPS is a serious design problem IMHO, just as side note ;)
Actually, it's exactly the opposite. You want physics & logic to be fixed though, while interpolating in graphics and running as fast as you can (until you get VSync). Nevertheless if you use Ogre's animation data for physics or logic, you'll need them to run properly with fixed framerates (I clone Ogre's data to use in physics for motion extraction, for calculating joint points for my rigid body constraints in Havok, and to get the mesh shape information for complex objects, typically buildings).
no time to read right now, but will go through that :)
dark_sylinc wrote: Sure, I'm just so convinced about SVN (I guess this is the time where I'm acting selfish)... I'll be uploading v1.3 sometime around this week (whether I choose SVN or Hg) then upload the changes (so we have two commits) and you can see the difference. Beware, I'm anticipating a busy week :roll:
BTW, no problem about forking the project, just make it more obvious it's a non official/fork release. Currently it looks like it's an official release (Because of the name and/or version number).
thanks, the diff would be nice to see :)
also, i named it like that so you can reuse it, not to release something official, i will remove the files now so you can release them officially later on :)
User avatar
toglia
Gnome
Posts: 336
Joined: Sat Dec 08, 2007 4:28 am
Location: Canada
x 7

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by toglia »

dark_sylinc wrote:I know how Blender works because I use it on a daily basis
I just hate filling my head with so many different hot keys. And most probably Meshy will live along some of these 3d editing programs. I'm even impressed you didn't try to replicate Blender's camera keys so you would work seamlessly.
dark_sylinc wrote: IIRC Ogre has a raycasting function which works up to triangle level. Once you get which triangles (I hope Ogre gives triangle index data) I can get which bones are affecting that point and then transform it during animation.
I would like to see how would that work.
User avatar
tdev
Silver Sponsor
Silver Sponsor
Posts: 244
Joined: Thu Apr 12, 2007 9:21 pm
Location: Germany
x 14

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by tdev »

toglia wrote:
dark_sylinc wrote: IIRC Ogre has a raycasting function which works up to triangle level. Once you get which triangles (I hope Ogre gives triangle index data) I can get which bones are affecting that point and then transform it during animation.
I would like to see how would that work.
see http://www.ogre3d.org/tikiwiki/Raycasti ... ygon+level
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by dark_sylinc »

LOL the amount of implementations in that link is incredible. Thanks for the link. It will make my work a breeze
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by duststorm »

I'd like to thank you for your great work and your generosity for sharing this with us all.
I've used it and have been able to correct some animation problems with a model I have.
I'm still using Ogre 1.7, so I had t recreate the models (axis, bone and such) that Meshy uses to be in ogre 1.7 format. Compiled meshy for linux and it works like a charm! :)

The feature list is getting real interesting, especially with the addition of assimp model importer.

Finally I'd like to congratulate you on your fine work on documenting your tool on http://code.google.com/p/ogre-meshtool/
The documentation looks real good, with even a linux compilation guide.

EDIT: If I'm correct, the google code project is a fork from your project. I only realized this later :)
Last edited by duststorm on Tue Oct 04, 2011 8:46 pm, edited 2 times in total.
Developer @ MakeHuman.org
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by dark_sylinc »

Ogre Meshy 1.4 IS OUT!

Go get it!

What's new in 1.4?
  • Added ability to take screenshots with F12 key. They're saved in the documents folder.
  • Fixed rare crash when using a material defined outside a resources.cfg but which depended on shaders defined there; and resources.cfg file was reloaded.
  • Windows: Application now comes as an installer, with file association included for ".ogre" files.

    The following changes have been mainly brought to you by "tdev" (Thomas Fischer):
  • Fixed mousewheel. It's now working. Also fixed imprecision (int->float)
  • Log window hidden by default, only shows upon error or through menu
  • Log window is now coloured.
  • Enforcing vsync: otherwise cpu waste and lots of warnings upon window resizing
  • Reloading a mesh no longer resets camera position
  • Now possible to close the log pane, overrode the panes' close button event
  • Windows: logs and config now stored in the user path
    FPS & batch count displayed on bottom

    The following change has been brought to you by "toglia":
  • Linux: Fixed colour picker dialogs.
My apologies for all the other requested features that haven't been added yet. I've been extremely busy and stressed. I hope you'll understand.
At least Jacmoe got his request after so long ;) It comes with added value: the screenshot name contains a timestamp, the name of the mesh, the current animation being played, and the animation time at which it was taken. I was in need for that feature, saved me a lot of time.

@tdev:
VSync is disabled in Linux. Somehow the GUI becomes reeeeeee aaaaaaaaalll lyyyyy laaa aaaaaaaaaaaa gggggggyyyy when enabled.
I've decided to use Mercurial to please everyone. I'm looking whether Bitbucket or Sourceforge, which one might a better choice.
I haven't moved the toolbar yet. I'm planning on making it dockable, which probably adapts better to everyone' needs.

@OGRE Team:
Taking a screenshot in Linux results in a corrupted image (colours are fine, the image bends diagonally). Possibly a pitch vs width problem.

@Everyone:
Woooow, 1000 downloads in two months? (810 downloads in one month to be exact). That's 25% of Meshy's downloads until last release in it's lifetime. Thanks everybody!

Cheers
Dark Sylinc
dermont
Bugbear
Posts: 812
Joined: Thu Dec 09, 2004 2:51 am
x 42

Re: Ogre Meshy 1.3 - (Mesh viewer, Now supports Linux!)

Post by dermont »

dark_sylinc wrote:
@OGRE Team:
Taking a screenshot in Linux results in a corrupted image (colours are fine, the image bends diagonally). Possibly a pitch vs width problem.
Not sure if this is a problem with Ogre (I'll leave that to the team to comment) but I ran into similar problems with gtk+ and WX ( though GL implementations such as wxGLCanvas were fine). Maybe as a workaround you could take a screenshot of the GdkWindow; for gtk+2 something like:

Code: Select all

void wxOgreRenderWindow::snapshot()
{
    GtkWidget *widget = m_wxwindow;
    GdkWindow *gdkWin = GTK_PIZZA (widget)->bin_window;


    gint width, height;
    gdk_drawable_get_size(GDK_DRAWABLE(gdkWin), &width, &height);

    GdkPixbuf *pb = gdk_pixbuf_get_from_drawable(NULL, 
                       GDK_DRAWABLE(gdkWin), 
                       NULL, 
                       0,0,0,0,width,height);
    gdk_pixbuf_save(pb, "./TEST123.png", "png", NULL,
                     "compression", "9",
                     NULL);
}
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.4 (Mesh viewer, Windows Installer & Linux s

Post by dark_sylinc »

I'm pretty much sure since I just make one call and Ogre handles the rest. I've worked in Graphics applications a lot; and this is a common pitch != width problem, a typical bug that happens very often when copying the image from one buffer to another in a different format (i.e. at the moment the screen pixels are copied to a another buffer, like the compression buffer)
This is actually a serious bug since 99.9% of the time there's a potential of a buffer overrun. Which means in a few cases, OgreMeshy may crash when hitting F12 in Linux
dermont
Bugbear
Posts: 812
Joined: Thu Dec 09, 2004 2:51 am
x 42

Re: Ogre Meshy 1.4 (Mesh viewer, Windows Installer & Linux s

Post by dermont »

dark_sylinc wrote:I'm pretty much sure since I just make one call and Ogre handles the rest. I've worked in Graphics applications a lot; and this is a common pitch != width problem, a typical bug that happens very often when copying the image from one buffer to another in a different format (i.e. at the moment the screen pixels are copied to a another buffer, like the compression buffer)
This is actually a serious bug since 99.9% of the time there's a potential of a buffer overrun. Which means in a few cases, OgreMeshy may crash when hitting F12 in Linux
Sorry I didn't mean to suggest there wasn't a bug with "screenshot", as you say from your experience this is a common problem. I partially resolved my problem with screenshot and gtk ( a problem with pixelformat ).

Anyway the following code works for me where the client size is 4x4 pixels less then the renderwindow height/with)

Code: Select all

    //Ogre::PixelFormat pf = mRenderWindow->suggestPixelFormat();
     wxSize size = this->GetClientSize();
     int w = size.GetWidth(); //mRenderWindow->getWidth();
     int h = size.GetHeight(); //mRenderWindow->getHeight();
    Ogre::PixelFormat pf = Ogre::PF_A8R8G8B8;

    Ogre::uchar *data = OGRE_ALLOC_T(Ogre::uchar, w* h * Ogre::PixelUtil::getNumElemBytes(pf), Ogre::MEMCATEGORY_RENDERSYS);
		Ogre::PixelBox pbox(w, h, 1, pf, data);

    mRenderWindow->copyContentsToMemory(pbox);
	Ogre::Image().loadDynamicImage(data, w,h, 1, pf, false, 1, 0).save("./Test.png");
	OGRE_FREE(data, Ogre::MEMCATEGORY_RENDERSYS);
The only other change I made was in the wxOgreRenderWindow , since you are using a parentWindow handle.

Code: Select all

        Ogre::WindowEventUtilities::messagePump();

		msOgreRoot->renderOneFrame ();

So I'm guessing that in in wxOgreRenderWindow::OnSize it should be(???):

Code: Select all

//wxSize size = evt.GetSize ();
wxSize size = this->GetClientSize();
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre Meshy 1.4 (Mesh viewer, Windows Installer & Linux s

Post by dark_sylinc »

Mmmm interesting. So the renderwindow has the client's size but the actual's OpenGL is lower? That could explain it. I'll try to see what happens when I take a screenshot in fullscreen SampleBrowser and in windowed mode.

This may be an Ogre bug, or rather Ogre has no way of knowing the actual size when using it together with wxWidgets.
Post Reply