moniker

@Nimi would Occlusion culling be possible? on the gif I posted above you can see how frustum renders everything on the camera angle eyesight while occlusion also saves resources by not rendering pieces of scenario which are hidden by other pieces of the scenario. Left: FPS rendering performance only with Frustum Culling and then with Occlusion Culling activated, at the eight different selected View Points. Right: Discarded mesh percent, first with only Frustum Culling and then activating Occlusion Culling, at the eight different selected View Point.

Nimi has announced frustum culling for 1.3.0 This should increase FPS. However even without FC active, what's on screen is so simple that it doesn't make much sense that the framerate is so low. I have a 3950X with a 3090 RTX and 32GB RAM so hardware limitations are out of the question, and I like said stats show that resources are barely being used.

As im trying to find ways to improve performance, I would like to know what makes you get the biggest hit on framerate? By the time I have set a schematic, load up some characters (not even overly complicated rigs) and start adding keyframes, the framerate is already so unpleasant to work with, and I have an expensive computer. Anyway, what I have found in my experience: 1) Opening the Active Camera window kills framerate pretty much in half 2) Having the "controls, wireframes and highlights" setting enabled makes it worse 3) Keyframes, as you add keyframes, it gets worse By the time you've done 3 minutes of animation it gets really bad. Hidding pieces of the schematic im not using makes it better, however, the Active Camera window makes it unsmooth again. There is something very specific going on considering the simplicity of what's on screen, framerate should stay 60fps in non-render mode but it doesn't. Stats for my project right now are 1.8 GB RAM, 4% CPU, GPU 3% yet the FPS is so bad (again, in non-render mode). Something is going on. Why is the FPS so bad if the CPU and the GPU are barely doing anything?

___________________________________________ ############################################################################################ FATAL ERROR in action number 1 of Destroy Event for object obj_timeline: PerformEvent recursion depth failure - check for infinite loops, check objects for parenting ############################################################################################ -------------------------------------------------------------------------------------------- called from - gml_Script_tl_event_destroy (line 62) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_tl_event_destroy (line 14) called from - gml_Object_obj_timeline_Destroy_0 (line 0) called from - gml_Script_action_tl_remove (line 29) called from - gml_Script_tab_timeline (line 648) called from - gml_Script_panel_draw_content (line 87) called from - gml_Script_panel_draw (line 98) called from - gml_Script_panel_area_draw (line 56) called from - gml_Script_window_draw (line 20) called from - gml_Script_app_event_draw (line 7) called from - gml_Object_app_Draw_0 (line 0) Deleted a rig and this happened.

Well, one would expect that copied keyframes are pasted accordingly, so I wasn't sure if putting it on bugs/issues or suggestions. Im not suggesting a feature, it's just a basic feature (copy/pasting of keyframes) that already exists but doesn't fully work. Technically an issue with an existing feature as it stands.

If you have a default Steve model you can do it, but as soon as you start adding stuff (parented objects) it stops working. Even if you have 2 identical rigs, you can't copy keyframes from one instance put them into the other, it pastes it into the same one you copied from. Same for exporting and importing keyframes. For some reason the program can't copy-paste more than one object line at once. This makes rigs pretty much useless unless you never use movement cycles.

It's not even that complex. Those surfaces are just some rig of a plant, the surfaces are leaves. This is just basic behaviour in any GUI for a software irrespective of how complex your project is anyway. It's like not being able to select many files at once to import as resources, right now you have to go one by one. This is already fixed for 1.3.0 I believe. Another thing that would improve workflow a lot is being able to have the Camera timeline visible at all times, because you build the animation around the Camera timeline to match the keyframes to the scenes, which means for every keyframe you draw you have to constantly scroll up and down like a madman to make them fit within the Camera keyframes for the scene. I've suggested a "sticky object timeline" solution. All of that slowly adds up and the end result is that the workflow is improved even if you thought you wouldn't make much use of it at first. It's one of those things.

Suppose you have a walk animation cycle and you want to make it match the speed of your character which in this case, goes really slow, so what you would need to do is go keyframe by keyframe and add gaps in between frames to match the speed at which the character is moving. Doing this manually is a waste of time. It's one of these things. Here you can see how other editors do this in 2 seconds: So the idea would be to select the keyframes you want to expand/contract and while holding a key (like alt or shift) and draging to the right it expands the gaps and draging left it contracts them. Problem solved.

And something else comes to mind: A button to expand all/collapse all, if you want to select everything you have to manually expand all folders and then collapse them again also manually. Something like this: Also I realized it should be ctrl + click = select objects individually shift + click = selects the range Just like on windows or in most software.

In some cases you would need this. For instance you are making an episodic series and you want to export everything exactly as it ended on episode 1 into a new project because by the end of episode 1 the software is already struggling to deal with the keyframes. To ensure everything is exported exactly as it ended, you should select literally every single thing at the end of episode 1, this means expanding every single folder, then selecting every single object timeline, not just the folder but the contents of the folders to guarantee everything is exported in its right place, and then delete all keyframes before that, then move them to frame 0, now you can export this and import it into a new project for episode 2. For this having the ctrl+shift feature would save a lot of time. Any software has this feature, if it was added the net result would be positive for the software, non-debatable.

Like I said above, im aware. The problem is, if you have a massive list of objects, you have to scroll throught an insane amount of time when you could simply click first and last while holding ctrl+shift as you can do in most programs. Look how tiny the scroll bar is. No matter how much tiddying up you want to do with folders, some rigs just doesn't make sense to add stuff that belongs in the same category to different folders, these surfaces are part of the same thing, so there isn't a point in adding up folders and more folders. It would make more sense to have the ctrl+shift range selection that every software except Mineimator has.

Suppose you have a rig that has massive amount of different objects on the timeline, which is the usual case, and you want to select half of them. You would need to click and start scrolling up or down an insane amount of time in order to select all the stuff on the timeline. Why not just add a way to select entire ranges. If this is not clear enough, basically imagine objects are files here: Selecting files individually while holding shift already works, however it lacks selecting entire ranges. It should be: ctrl + click = select files individually shift + click = select entire ranges Just like on Windows or in most software. Btw, when you have selected multiple timelines and click on "Select all keyframes on this timeline" one would expect that all keyframes on all selected timelines get selected, as it stands it only selects the one you clicked. This means that you have to go one by one clicking on "Select all keyframes on this timeline" which if you wanted to do this for a ton of timelines would be a waste of time.

Isn't it 1?

We would need something like this. Separate X Y Z and angle keyframes and interpolations for seamless movement. Trying to create a camera path manually as it stands that flows like that is not possible with the tools we have now. You could try to work around it in an awkward way by using folders and moving them to the right distance to rotate them and simulate a smooth curvature but it will not look proper anyway, plus trying to work with folders like that is a nice way to end up with an headache.

Will 1.3.0 have the sticky object option? I just waste so much time scrolling up and down to find the Camera on the timeline. Everything is built around the Camera keyframes, there should be a way to make the Camera timeline visible at all times as you scroll up and down. I think once this is implemented it will be insanely obvious how much it improves workflow. Im going to try to post a gif with how the idea should work later.

When you click right click on the timeline bar (the white bar with the frame numbers) to try to select a range to render, it just keeps going up. This has been happening for many versions now. I reported it but never was fixed.

"Texture horizontal offset" and "Texture vertical offset" should be able to get automated with keyframes. Would be useful sometimes when you want a scrolling texture.

Performance is pretty bad as you keep drawing keyframes alone, by the end of a 10 minute animation you usually have a big hit on framerate. Also having "toggle controls, wireframes and highlights" enabled takes another big hit on framerates, as well as having the camera window opened. I reckon Nimi was working on framerate improvements, for instance not rendering what isn't seen behind blocks. Im hoping 1.3.0 makes thing better.

Not sure what triggered that, I just was clicking undo and it crashed with that error.

The cyan bend circle allows you to bend in a range of -180 to 180 irrespective of what the actual bending for the part is (for instance, a default arm is from X: 0 to 180º if you use the bar to bend which is correct, instead of the circle). Is this fixed for the next release?

Wrong. This isn't even about adding new features but about fixing a bug that causes a memory leak. Even David and Nimi upvoted my posts about it.

That has nothing to do with a memory leak.

This is not how software development work. You have to put barriers in your software so memory leaks never happen.

The rig is not some super complex thing, it's just a medkit with some stuff inside. There's clearly something wrong going on in there.

You don't need to name every object, just the object you want to parent to.