polymaker / ldd-brick-editor Goto Github PK

I see you have some hard-coded keyboard shortcuts for ONLY SOME options. Why not enable user to defined keyboard shortcut for any option?

For example, I find it pretty annoying/frustrating constantly going to menu and clicking Import 3D file a sit has not keyboard shortcut. It be great if we could define one.

Or is there some hidden option how to do it? Cos I was looking thru the settings/config files but did not find the place where they are defined thus I am thinking they are simply hard-coded into the app, right?

It is quite common in most apps having the app settings menu under the Edit menu as the last option, definitely not under the tools (why - it is not a tool).

Another rather wish as this is non-essential once again: as I have placed icon of your app right beside the actual LDD icon I am almost all the time clicking the wrong one as they are basically the same! :-)

So what about new icon? Like what I would suggest as your app is creating G files, having it as a small letter "g" (to differentiate it from the ugly Google one) and also at least different hue of blue (in case you still want it to be in blue prolly because of connection to LDD which it has its icon in blue - right?). Maybe creating the small letter g from the bricks in the LDD? It'd be quite original...think about it, please.

When I import mesh via "File > Import from LDD" part name sin Project Tree have some anonymous names like Part0, Part1 etc. - why this? It would be much more logical to incorporate in some way also the brick ID into it.

I prolly understand your naming logic where you are taking it from the brick sections (g parts) where g becomes part0, g1 becomes Part01 etc., but this way we are missing the original brick name (ID) which is quite a pity I would say.

So you could implement it somehow, either replace the actual Part0 with brick ID + part extension - most preferable option to me (like 3003_g, 3003_g1, 3003_g2 etc.) or if you still want to maintain the actual naming logic then prolly like 3003_Part0, 3003_Part1, 3003_Part2 etc.

As for the interface: it looks too clogged and it is quite hard to orient there, so I would suggest something like this - rather small but important better GUI "differentiating":

Another thing would be GUI object sequence they appear in the GUI, like, for instance, physics section is the least important of those 3 sections - definitely less than boundings, thus logically it should/could be the last - one can omit it from the xml and the brick will work anyway in most cases (see my image sample above).

Also naming: when you have GUI sections under Part block you do not need to name each of the sections starting with the word "Part" as it is quite logical it is work with the part as it already is under the Part section (see my image sample above).

Another thing: buttons that do something with the parameters in the same GUI "block/section" should be the last object, not first. It is quite messy as one quite often hit the wrong button thinking it belongs to the other section + make all the elements having some common align logic, like place all on one side, besides it makes the GUI more pleasant to look at (see my image sample above).

Another thing that seems not right visually speaking is placement of the "Open files in" segment - having it the way it is, that is in top menu line is quite non-standard for that kind of GUI object (actually I saw something like that before but it still did ring wrong to me).

So I would suggest you moving it to the actual right panel (which I hope you will move to be on the left side sometime later as it has higher priority than the left panel for individual brick values) right under the top as the 1st value/option, so it would look something like this here:

• as I am looking at the picture now I would even suggest to changing the word "NAVIGATION" to more accurate word "PROJECT".
• and from this point of view further on I would even suggest saving the selected "Output in folder" values with the project itself beside having it still as a value in the app settings for cases when there is no project loaded, sort of default value one selected in the settings, thus each project could have this output path set individually cos there might be cases where you want only testing that is not outputing to the LDD folder and others you want to output to the LDD folder, so one do not need constantly fiddling with the output folder per project according to its needs which even more adds to the fact changing the name of the right panel to PROJECT and having this roll menu right under it. ;-)

I am not sure if this can be done in your app outside the actual 3D editor like Blender, but could you implement some simple UV manipulation similar to mesh manipulation, like changing of its position, size and rotation?

Reason: I quite often find the UV being slightly (well, sometime quite a lot) out of the correct position/size/rotation and it is a bit bothering to go zillions of time back and forward between your app and my 3D editor just to re-adjust UV - this way it was be great enhancement to the workflow of this whole LDD brick creation!

When you chose specific option for the "Output files in", it is not remembered upon next run of the app and is reset to the default LDD Folder.

I am not sure if I understood this correctly, but I suppose that when I select all the individual brick parts in app canvas, and chose canvas menu "Mesh > Merge meshes", they should actually visually merge into one object replacing all the individual parts on canvas and also in the Project Tree under its Elements section in the Navigation panel, right?

If this should be the case, then there is a problem/bug, as absolutely nothing happens - there are still all the separate parts and no new one (merged) is created.

Or am I doing something wrong?

When I export the brick mesh as 3D to be edited in a 3D editor (Blender in my case), it is in black.

Could you make option to set 3D file mesh output color? For instance, in LDD it is red by default (when in LDD EXTENDED MODE which I take/consider a profi user mode - most of us working with custom bricks probably already are using this mode exlusively, I guess).

Or could you at least set it to LDD's default red color instead of the black?

When 1 or more lines of comments are added (i.e. revision management) and the part is re-opened, the complete comments are removed.

I'd be great if we could - besides the "standard" loading of the whole brick selected from the table/list of LDD bricks you already have as a option - to be able to load individual .g brick part. After clicking this option open file dialog would open in the LOD0 folder where we could select one or even multiple different g parts of different bricks, not just the g parts of the same brick - this should also apply to the reversed option, that is direct output to 3D file.

Reason? I have many instances where I need/want to slightly modify just specific g part, not whole brick. Sure, I can simply load whole brick, export to 3D, and once in the 3D editor simply delete those parts I do not need. But it unnecessary adding additional work to be done when we could do it simple way described above right away.

This is really just a tiny thing: you see, I am JAVA programmer myself working inside the NetBeansIDE and I am just used to have the "tree" on the left side and the actual "object manipulation" part on the right. But we can see this same "logic" in windows itself, and in other win apps too, when there is the tree almost everytime on the left side cos we go from the top to bottom, from left to right, so the selection should/could be on the left as the 1st step...but I admit this is rather non-essential, actually just a wish.

I guess the headline tells it all. :-)
This would also allow you in the future to add other submenus to it in case you would have such, as the link to webpage, to updates etc.
This is a standard naming of the menu, I would say, as About is usually under the HELP menu.

And as I am saying this: you could also include some very basic manual for your app, like the basic operations and How-to. That would go exactly under the help menu.

It'd be great if we have some at least simple decor preview ability for decorable parts, cos that checkered A0-X0 style at the moment is basically of no help (hard to tell if the decor would be stretched or some other way deformed).

There could be context menu option after RMB on a decorable brick part be it in canvas or in the right panel for load preview image, after which the image would be stretched across the UV of that part.

Why we need to first load a brick to be able exporting it to 3D if that is really all we want?

I suggest you to add new menu option under TOOLS which could be called "Direct brick to 3D export", which could re-use already existing table/list of LDD bricks you are using for "Import from LDD", that is this one here:

That would simply directly export selected LDD bricks in that table/list and export it to the location defined in the "Output files in" without loading the brick to the app canvas as there is no need for that cos we only wanted to export it as 3D file to be able edit it in some external 3D editor like Blender.

And, of course, such exported brick should consist of all the different .g files the brick has, creating one single model, where each individual .g segment would be separate 3D object once opened in 3D editor like Blender (but I think you already have this specific "thing" implemented if I remember correctly, right?).

Also I would say that when you exporting LDD brick to 3D file you need to export just the brick omitting any camera and light - what for? There is no camera nor light in that brick, just the mesh itself. If one want to have camera and light added to the mesh inside the 3D editor, he can do it still by himself.

But still, if one would be exporting brick from the canvas, that is after some editing in your app (if editing is even possible there) then you could add also camera cos it would have its logic then (not light, as there is none in the canvas - do not try to be more Pope than Pope himself, as saying goes in my country, LOL).

I found out your app is pretty portable except it writes its settings to user folder in the system.

You could add option to app settings for "Portable mode" where - once selected/clicked - all the settings would be written (copied if already present in the system user folder) to local folder (that is inside the application install/extracted folder) named for example as "Profiles" with the specific user folder, so there would be folder Profiles containing folder "specific-user-name" that would contain all the files from the system user folder.

Also in this regard those 3 font files should be place to some folder inside the main app, let's say "Fonts" and taken from there instead of installing it into the OS.

This way we could simply copy the app folder to USB stick and run it anywhere we want with all the settings!

And if you agree on this then you could also add it as simple zip file instead of the installer (for the Portable version), so the user would just extract the zip file and that's it: he can run the app right away by dbl clicking the app exe in the extracted folder!

I assume one cannot export the brick (g file) without generating the bounding boxes first, so it would be only logical to be generated automatically right after importing a specific brick part into the project. In such case I do not see need for the generate button anymore: if one want to adjust the values himself he can, of course, but once the bounding is autogenerated there is no expectation to generate it once more manually.

Or OK, there might be reason having those btns present still: if one is editing the values and make some mistake he could still hit the button so the values would be generated once again - in such case I would you to take in consideration renaming those buttons from "Generate" to more accurate "Re-generate"

But still the autogenerated boundings should be added - right?

On systems with elevated privileges like mine the app crashes like 1-2 secs after opening as it has not access to registry.

Now I am not sure if this is a bug or just a common behavior. Anyway, it'd be great to have it as some sort of WARNING like during install process or something. Like a notice in install window that if the app crashes after opening it just run it always as administrator.

You could select the 1st input filed (text filed) automatically in cases where we have to input some value to chose from objects/files, like for example in "MENU > File > Import from LDD", where focus is at the moment on the 1st table object (brick) which I find less useful than if it would be on the search input text filed where we can type the brick ID manually: I would not scroll thru the table when I know what I am looking for by brick ID, right?

Typing it into the search box is much faster thus supposedly the focus on the search input textfield makes more sense...well, at least to me, of course.

The library "freetype6.dll" could not be loaded.
This library is used to draw text in OpenGL.
The application can still work but no text will be displayed in the viewport.

If a brick has several g parts (that is more than 2: "main" g and 1 decor) it may become quite messy, like in this example where it is a bit harder to orient/differentiate between separate parts.

My suggestion is to introduce g parts colorization - just for the app canvas, of course, something like this:

Either having new settings section "Brick parts colorization", where one would manually define color for each brick part up to let's say 15th order (I guess that is the highest part section I was able to find, specifically brick 75972), or some auto-coloring code that would get all the brick section and define different color for each of them by the app itself thus no new settings section would be needed..

I find bothering confirming all sorts of small warning/info windows (not saying your app has millions of those, prolly not - more like a few, but anyway), like when you export a brick mesh into 3D just to close it (to click on the "OK" confirmation button informing me about successful export) to be able continuing work with the app.

You could add settings checkbox option for something like "Autoconfirm all warning and info windows" - in this case no warning/info window9s) would appear as they would be automatically taken as confirmed before they even appear.

Hi polymaker!

Do you know if it is possible to add groups to LDD? I am working on the Braille bricks, but I do not want them to clutter the regular bricks category.
Same for ZNAP, at some point ZNAP parts might be added which would require their own category.

Is this possible?

Kind regards,
Stephan

I find it quite annoying that the app constantly defaults to user Documents when I want to export the brick as 3D mesh (file), but I, for example, want to always export to Desktop instead (it happens often that I do not pay attention and erroneously export it to Documents only to later trying to find it for several seconds somewhere on the Desktop not realising I did not change the output directory in the prompt window during the 3D mesh export, ah).

Could you add a new settings option for the 3D file output directory or at least make the app remembering the last one between sessions, please?

What about adding specific 3D files that would contain basically just the edges of the supposed outlines we created ourselves to avoid situation where you app cannot generate them or even crashes when trying to, hm?

I guess this would even make the process quicker than to wait for the app process and logic to generate those.

One would simply RMB somewhere in the canvas or the right panel and there would be new context option something like "add Outline Edges 3D mesh": once clicked we could provide our outline edges 3D file (dae/obj) which would be basically just a vertexes and edges with no faces and that would be src for creating outline edges on the brick once in LDD. This of course wouldn't mean that the actual option to generate outlines would disappear, no, it would only further expand option to create them in scenario I described above. It would also enable user to define exactly what he thinks should be highlighted as the outline edges of the specific brick. Once added it should become grayed out in the context menu until it is removed form the brick, of course.

I think to implement this would be really easy, wouldn't it?

When you save project - .lpp file - and let Windows associate it with your software, then upon dbl clicking it and opening it in your app the project is completely empty.

I am somewhat baffled by the fact you have editable values texts and label texts (read only) in the exact same visual style that is further messing things up as it is not clear right away something is editable and other is not.

What I would suggest here would be changing to color of label texts to some more light color resembling some other already used GUI colors, for example color of the GUI object borders or something, simply not having it in the very exact color as editable texts (values). I would even think about additional bolding of the label texts, where editable values would remain in normal font weight.

Of course, editable values text would remain as they are, that is black text color on white background.

When starting 1.0.8.0 (x86 or x64, on Win7), the following error occurs:

System.NullReferenceException: Object reference not set to an instance of an object. at LDD.BrickEditor.Settings.SettingsManager.ValidateLddPaths() at LDD.BrickEditor.UI.Windows.BrickEditorWindow.InitializeAfterShown() at LDD.BrickEditor.UI.Windows.BrickEditorWindow.<OnInitializationPopupLoaded>b__67_0()

and application sits around with "Initializing Resources", apparently doing nothing (I've left it for more than an hour, at least).

Would it be possible to export whole LDD model (whole content of .lxf file) to 3D, if we can export single brick?

Of course, in this case every brick position should be recalculated according to its matrix from the lxf file so that they would not appear all in the center crossing one another.

I think this would be another great extension to your app, as there is none such app regarding LDD AFAIK (I do not consider native LDD export a sit is useless for this, meaning for the 3D import into 3D editor, besides it is faulty mainly for the flex bricks).

In fact I can tell this is possible as I already did this several yrs ago for my own personal LDD Java app, but having it as a part of your app would be simple big thing so I do not need to skip back and forth between those two.