News: https://github.com/mick-p1982/mm3d (experimental fork)

[m-7761]

Hi! I kind of fell off the map for a while. Just announcing I've published my project files that I've been writing about here for a minute at https://github.com/mick-p1982/mm3d .

My disappearance was mainly way too much time I spent on making GTK work to some degree since I didn't want to publish with just Windows... as part of the reason I'm doing this is to commit to cross-platform.

Working on GTK really stressed me to my limits, so I'm trying now to just purge myself of it, since I really wanted to be working on the core Model and undo/redo system by now. Using wxWidgets to implement GTK was pretty much a nightmare, partly because I'm implementing in terms of an additional abstraction layer that doesn't fit neatly into wxWidgets one-size-fits-all application model.

So, I have only bare minimum support for Linux like systems, and don't know if it will even operate. I can use it with GTK3 and WSL via a modified XWin X server. I am interested to know if it works with a Linux X server (I assume there may just be one Linux X server but don't know... or Wayland) if anyone wants to try it. I only tested it with GTK3 (wxGTK3) but may go back and work on GTK2 since I have that on both Cygwin and legacy WSL Ubuntu. I did do early tests with GTK2 but switched to using a newer CentOS installation since it had a better debugging environment.

Off-topic: My time lately has been divided between this and working on transferring some personal websites to a new host that's presented a number of challenges (become a project in itself) but other than this I'm mainly interested in getting back to work with MM3D. I just need to put Linux work aside.

This branch (widgets95-ui) has a radically altered file-tree since I took the time to purge everything and replace its build-scripts with CMake. Sometimes letting go of the past can be a fresh start, but obviously I can't maintain everything. The number of source files is considerably less, and the updates are frozen to when I started my work. Something I intend to do is comb through all of the changes here and manually put ones in that make sense to.

The ZIP files are just some directories and things it made sense to retain in some form for reference sake.

From what I can tell the wxGTK3 version is virtually identical except that the HTML help system may or may not display properly depending on if the X server clips correctly. It may crash in places since I haven't done extensive testing and GCC builds different from Windows but things basically work. I had to draw the line for the time being. Debugging with GDB is very painful. The best tool chain I ended up with was Visual Studio Code that basically requires closing and reopening every time I do a debug session and is so slow to step I feel like I'm on drugs.

At this point I'm just blogging. Anyway, this code is definitely better than the existing code. It's better organized, much less bloated, much better quality, much more maintainable, and the user-experience is improved in a lot of ways, so maybe take a look at it, or don't is fine too. It's definitely rough and rushed to publish. I want to do phase 2 to actually improve on the core data model that isn't viable in its current state... I think it's so poor that MM3D can only work with extremely low-poly models because computers work so blazing fast that something that is a million times inefficient can actually work in real-time.

[m-7761]

I've put together a very simple single EXE (Windows) plus docs demo here (https://github.com/mick-p1982/mm3d/releases/tag/win32-demo) to be able to share the program with Windows users.

If anyone has a Windows box please try it out and tell me if it works. In theory it uses pure static runtime that seems to work on my system, but it can be hard to tell if things will really work on a regular user's computer.

[ghost]

Well, first I have to say that I don't even understand a single piece of the code of this project, so I will not help you much. Apparently, you want to know if your experimental demo works for Windows users. If you want to know if it starts, and don't crash, than YES, it works (at least for me). I am on Win 8.1 (64-bit). Although there seems to be some differences to the mm3d that I use by default (like missing frames between vieports).

[m-7761]

Thank you. The black around your toolbar buttons doesn't happen on my Windows 10 system. Giant screenshot BTW! My toolbar has gray behind the buttons like the gray background. I wonder if your system can't make them transparent so uses black instead, or if it's because black is your theme color.

Mine has light blue highlights on the selected item that looks identical to the Qt version here. Your window doesn't have a frame around it either. I guess it's in fullscreen mode, or maximized. F11 can remove the titlebar if you're interested. Not super useful.

Although there seems to be some differences to the mm3d that I use by default (like missing frames between viewports).

It's somewhat redesigned, as you can see if you spend more time with it. I hope Maverick will adopt some of the enhancements where possible. I'm designing it to be practical for serious work.

Word of warning, the text boxes don't have undo/redo support. I rushed this out because I've been sitting on it for so long (mainly working on trying to make Linux work) and I mainly just wanted to get the files out there. That's something I didn't work on.

I'm probably going to be mainly working on this still for the time being, so I can use testers. I'm either going to begin overhauling the core code or work on loading the models I need to edit into it. I may be doing the latter since it will be more exciting and provide a backdrop for the more dry work. My models use the frame animation facilities, so as soon as the data is in there I will have to pull out the stops that make it so you can't edit those models. The next problem undo/redo is really inefficient, so I have to solve that and theoretically the reason you can't edit the frame animated models is because either undo/redo isn't implemented for them or that it's too slow to be practical owing to inefficiency.

There's nothing to worry about because the way MM3D is programmed is comically inefficient, so it's not like there is a technical problem, it just needs rewriting to be less maniacally insane! There are some neat (and useful) features like you can work with the Perspective views if you enable selection on them, and also toggle the new default tool (visible in your screenshot) to be able to rotate the Ortho views. Using Shift will drag/rotate/zoom all views at once. Keys like Q can toggle (not all can) so you can toggle quad view on and off and if switching to single view it will switch to the view that your mouse is over. It also remembers views from previous viewport layouts, so that lets you efficiently switch between layouts. And there are features for swapping the views horizontally and vertically.

I can work on the text box undo/redo thing in short order if anyone prefers using this over the Qt version here. Mostly it's a faithful translation. I didn't leave anything out but neither have I tested everything as thoroughly as I could have. But I did test things pretty thoroughly, but new software always has some mishaps.

EDITED: Ah, I see your title bar is centered, so you must be using Windows 8. I actually think that's pretty cool, but the rest of 8 is inexplicable. I think maybe your toolbar is using the old Windows classic style toolbar. Funny if so since there is a manifest. Thanks again for being the first to give me feedback. You may have the honor of being the last too! Only because I often get no feedback... this universe can be soul crushing.

[m-7761]

On second look there is some really weird stuff happening with your toolbar. Is that normal for other programs? It looks like the selected tool has a checkerboard background and as for the others they are clearly transparent since they go outside the bounds of the buttons, but there still seems to be buttons there too, that dark gray in this cause, and possibly embossed.

Some of that could be JPEG artifacts, but the checkerboard looks more pronounced than that. Sorry if it looks bad. Maybe there is a way to fix it doing something manually that is automatic on Windows 10.

On Windows 10 the unselected buttons have just the image, and the selected has a transparent light blue highlight.

[m-7761]

I am on Win 8.1 (64-bit).

If you want to try I added wxTB_FLAT (assuming same as TBSTYLE_FLAT) to the toolbar to see if that makes Windows 8 use a simpler toolbar model that may not be so weird:

https://github.com/mick-p1982/mm3d/releases/download/win32-demo/mm3d-portable.zip

EDITED: Oddly it changed the spacing on Windows 10, perhaps removing some extra spacing that seemed like a bug to me before. So I have to play with the spacing now, but I think this suggests that Windows 10 was forcing the flat rendering model but using a non-flat layout, so hopefully this is onto something.

EDITED: Reuploaded it with new spacing. The buttons were cutoff. It's actually hard to do the spacing with the settings provided by the Win32 API, maybe harder since wxWidgets manages the toolbars.

[ghost]

As I said, I'm no expert, nor I do some coding for mm3d, so I think I can't really help a lot. I'm just learning how to work with mm3d. Here is a new screenshot to see your changes: I'm not sure if the missing frames are an enhancement. Though, you are more competent than me, so I don't know. Probably it would be good to do small steps as far as redesigning is concerned. I know a few people who want to become familiar with mm3d. For beginners it is often frustrating to learn software (workflow) just to experience that newer versions or forks change their workflow/appearance in a very drastical way. Btw, it seems your experimental demo always starts in minimized window mode. Question: How can I change language? I did update the german language translations (and still working on those files + rewriting a german manual for mm3d).

[m-7761]

Thank you once again. That's probably as good as I can make it without switching to a different version of Windows myself sometime. It's not unbelievably bad but I can't begin to imagine what Microsoft is trying to accomplish with that way of highlighting the selected tool.

To answer some of your questions: Why do you want space between the views? This is how Blender does it. It's better to render that way also. The way Maverick does it actually allocates the textures multiple times on your video card, and if it put the geometry in video memory it would have to do the same for that as well. The space between is wasted space anyway.

As for German if you are interested in helping I'd be happy to use the opportunity to work on a localization feature. At the moment there isn't any since this build removes Qt that is how Maverick's localization works. The UI system is brand new, so it doesn't do localization yet. The "message catalogues" will have to be redone from scratch in a new format. The Qt format isn't very good, but it can't be reused either.

Since this is an experimental project that is more of a stepping stone than anything else for me, localization isn't a top priority, but since you say (as I understand it) you are transcribing the manual and other things, I can try to accommodate your work too. For me the manuals are so big (and a little bit low on insight and high on information that is very obvious and so maybe time-wasting to read) that I don't think I can really address them myself. It might even make sense to write a new manual and translate that into English. A briefer manual would be easier to maintain and digest.

Currently there is a problem that building the manual uses an obscure template system and Perl to build it, so I think it would be better to rethink the manual's format, using more straightforward HTML. I've learned wxWidgets has a wxWebView widget that is really just a web browser. Qt probably has something similar. That would let frames and JavaScript be used by the manual for instance. It sounds extravagant, but it would likely just be easier to implement and maintain in the long term.

I think it's possible to turn MM3D into a no-nonsense noncommercial 3D modeling package that could be shared by many applications, like middleware. There is a great need I think for something like that. The world doesn't benefit from yet another modeling package very much, but it really needs noncommercial resources in this domain.

My eventual goal is to apply this work to COLLADA in an all new modeling software, but I also plan to use MM3D in the immediate term and maintain it afterward. That could be for the next couple years very easily. Doing COLLADA will require a different kind of modeling software that is more like HTML editing software, kind of like how your browser probably will let you inspect/edit this webpage. COLLADA is kind of like a webpage. I've already done a lot of work for it that can be read about here (https://www.khronos.org/collada/wiki/ColladaDOM_3) but am having some difficulty translating it into a full featured modeling package.

EDITED: What do you mean by minimized?

Btw, it seems your experimental demo always starts in minimized window mode.

It should start centered on screen, but it doesn't restore a maximized or fullscreen state. It doesn't record position. Minimized suggests it's only visible in the taskbar. Is that what you mean? Windows 8 doesn't have a taskbar right? If so, how do you find it? In any case, that's definitely not normal, but I can't imagine why that would be either.

[ghost]

Yeah, sorry, minimized is the wrong term. I think in english people call a not maximized window 'restored', 'scalable' or 'normal'. In other words, your experimental demo starts not maximized, or in full screen mode.

[m-7761]

Sometimes programs do restore the maximize state (and I could add restoring position too) but for me that's very annoying, since I want programs to not obscure my workspace when I start them, and it means you don't know what state it will be in when you start, so I would have to make it a Preferences item if so. Plus my framework doesn't have a way to maximize the window at start, but it could fullscreen (F11) instead. Or I could add yet another extension to GLUT, but I'm trying to build an app framework that is only provides the bare minimum feature set for bringing a competent app to life.

I'm glad you clarified that behavior. In general you shouldn't expect it to behave identically to Maverick since that would defeat the point. It's improved in many ways, like you may notice that the window shape doesn't change while you work, which is a big improvement.

I may take your screenshot to the wxWidgets forum to see if anyone knows what's happening. I was going to bring up the "minimization" thing at the same time... had it been a real problem. In any case, I hope you can help me to work on a localization feature. I consider that very important and always do develop them, although usually no one is available to write translation scripts. I want to make the new localization system very simple, like the UI framework itself, but most likely it will use "gettext" localization for its message catalogue format. I want to organize it so the catalogues aren't redundant and so the programmer requires minimal code to enable it, ideally little to no code.

EDITED: I think if this UI framework were more mature, and tested on Apple it might make sense for Maverick to adopt it, since Qt is an ugly beast. Another user from here has expressed interest in working on the Apple front, but I'd be surprised if they do get to it. I don't have enough incentive to go to the lengths it would take to enable Apple support in my own home where I do my work.

[m-7761]

@KuehnhammerTobias I asked about the toolbar thing in the wxWidgets forum here (https://forums.wxwidgets.org/viewtopic.php?f=23&t=46644) and we concluded it's probably something unusual about your black/gray (High Contrast?) theme that is the culprit... if you want to investigate further I think it would be interesting to here about. I may try to borrow a Win 8 laptop this weekend to do tests.

[ghost]

Yes, the unusual look you have noticed is the result of the theme, I guess. I always choose dark themes (if possible) to protect my eyes. As you get older, you will realize how important this is. I really recommend protecting your eyes. Especially with modern, calibrated monitors.

[m-7761]

My newest monitor has a switch that turns the screen yellow that works well to reduce eyestrain. I think it's recommended for at the end of the day or for long staring sessions. I sometimes use it at all hours but I don't want the screen discolored all of the time naturally. But just changing theme is not enough I think.

Do you have a theory why changing your theme changes the selected tool to look ugly like that?

[ghost]

Who said it looks ugly? Joke aside, no, I don't have a theory why changing my theme changes the selected tool in that way.

[m-7761]

For the record there's a follow-up to this topic here (https://github.com/zturtleman/mm3d/issues/134) that represents a second round of work and a much more polished user experience.