danini-the-panini / mittsu Goto Github PK

Whenever I try the tank demo, the memory usage of the demo increases infinitely

Just after opening

about a minute later

In my THREE.js code, as well as OBJLoader (which is already in mittsu), I use:

• STLLoader
• ThreeMFLoader
• PLYLoader

These are all currently in the "examples" section of the THREE.js code rather than the core, I'm not really sure why. If I port them to Ruby, would you be OK with them being in the core, or should I perhaps create a separate mittsu-extra-loaders gem?

For my use case, I want to manipulate some 3d object files in Ruby, but I don't need to render them; instead I'm using THREE.js in the browser for that. So, in the interests of minimising dependencies would it be possible to make the library work without pulling in OpenGL unless a rendering context is created? I tried to use it without glfw3 installed just to see if it would cope, but it wouldn't start up.

This could perhaps either be done by adapting the code in the library as-is, or for a more extreme solution, splitting the non-graphical stuff out into a separate gem, something like mittsu-core. Do you think either are possible? I'm happy to try this, but it would be good to know what approach you'd prefer I investigate before I do so!

Is it possible to capture the cursor?

By the way this is a really neat project.

Does Mitsu have a documentation ???

Hello jellyman,

First of all, thanks for your work on mittsu project! It's a very helpful gem for me to display 3d geometrical transformations of some music material.

I've found the next error that raises on require 'mittsu' (tested: mittsu 0.3.2, ruby 2.7.2) when there is a not used refinement on Object (and on Math per extension).

Example with a refinement on to_s method:

module RefineObject
  refine Object do
    def to_s
      super
      # do some other things....
    end
  end
end

require 'mittsu'

Raises this:

12: from /Volumes/Base/Composición/Proyectos/music/10 On Composition-Production/2020-10-05 Espiral [musa]/musa/graphic-support.rb:19:in `<top (required)>'
	11: from /Users/javier/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:156:in `require'
	10: from /Users/javier/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:168:in `rescue in require'
	 9: from /Users/javier/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:168:in `require'
	 8: from /Users/javier/.rvm/gems/ruby-2.7.2/gems/mittsu-0.3.2/lib/mittsu.rb:3:in `<top (required)>'
	 7: from /Users/javier/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in `require'
	 6: from /Users/javier/.rvm/rubies/ruby-2.7.2/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:72:in `require'
	 5: from /Users/javier/.rvm/gems/ruby-2.7.2/gems/mittsu-0.3.2/lib/mittsu/math.rb:22:in `<top (required)>'
	 4: from /Users/javier/.rvm/gems/ruby-2.7.2/gems/mittsu-0.3.2/lib/mittsu/math.rb:23:in `<module:Mittsu>'
	 3: from /Users/javier/.rvm/gems/ruby-2.7.2/gems/mittsu-0.3.2/lib/mittsu/math.rb:26:in `<module:Math>'
	 2: from /Users/javier/.rvm/gems/ruby-2.7.2/gems/mittsu-0.3.2/lib/mittsu/math.rb:26:in `each'
	 1: from /Users/javier/.rvm/gems/ruby-2.7.2/gems/mittsu-0.3.2/lib/mittsu/math.rb:26:in `block in <module:Math>'
/Users/javier/.rvm/gems/ruby-2.7.2/gems/mittsu-0.3.2/lib/mittsu/math.rb:26:in `public_class_method': undefined method `to_s' for class `#<Class:Mittsu::Math>' (NameError)

I think it is due to some Ruby internal trickery to implement refinements.

I have found a bugfix that resolves the problem (rake tests passed):

On lib/mittsu/math.rb replace BuiltInMath.methods by BuiltInMath.instance_methods (also it seems using instance_methods is more well fitted to your intention of replicating standard Math module methods)

BuiltInMath = Math

module Mittsu
  module Math
    extend BuiltInMath
    include BuiltInMath
    ### BuiltInMath.methods.each { |m| public_class_method m }
    BuiltInMath.instance_methods.each { |m| public_class_method m }

#....

If you prefer I can make a mod and send you a PR. Please, let me know what do you think.

Regards.
Javier

Hi, I know this is really obvious, but the animation is choppy even on a machine with very modern specs and a good GPU. I get a little pause every second or so. Is this possible to fix?

I am aware that ruby has a stop-the-world garbage collector, so I tried disabling it with GC.disable before any other code is run, but the result is the same.

Every time I try and run a mittsu program this error pops up:

And then it immediately closes does anybody know how to fix this so that it'll work.

Is there a way to render on demand for a case where there is no animation and the scene does not change unless there is explicit user input from the mouse of keyboard? All of the examples use the glfw_window.run method which calls glfwPollEvents. I'm thinking something similar that uses glfwWaitEvents instead is what may be needed, but I am completely new to this, so any guidance would be appreciated.

I have checked all the examples but couldn't find anything related to it.
Is there any helper method to do this?

Hello I was wondering how I can get the pixel values that are rendered to the screen. I got this so far:

module RendererPatch
  def take_screenshot(x,y,width,height)
    pixels = []
    glReadPixels(x,y,width,height,GL_RGB,GL_FLOAT,pixels)
  end
end
Mittsu::OpenGLRenderer.include RendererPatch

But I don't understand what kind of variable pixels is supposed to be. It's complaining:

/var/lib/gems/2.7.0/gems/opengl-bindings-1.6.10/lib/opengl_command.rb:246:in []: can't convert Array into Integer (TypeError)

This is the method source code from opengl-bindings:

GL_FUNCTIONS_ARGS_MAP[:glReadPixels] = [Fiddle::TYPE_INT, Fiddle::TYPE_INT, Fiddle::TYPE_INT, Fiddle::TYPE_INT,
                                        -Fiddle::TYPE_INT, -Fiddle::TYPE_INT, Fiddle::TYPE_VOIDP]
GL_FUNCTIONS_RETVAL_MAP[:glReadPixels] = Fiddle::TYPE_VOID
def glReadPixels(_x_, _y_, _width_, _height_, _format_, _type_, _pixels_)
  f = OpenGL::get_command(:glReadPixels)
  f.call(_x_, _y_, _width_, _height_, _format_, _type_, _pixels_)
end

PS: Thanks for the great library!

here's what i got:

/home/jay/usr/lib/ruby/2.3.0/fiddle/import.rb:86:in `rescue in block in dlload': can't load /home/jay/usr/lib/libglfw3.dylib (Fiddle::DLError)
    from /home/jay/usr/lib/ruby/2.3.0/fiddle/import.rb:83:in `block in dlload'
    from /home/jay/usr/lib/ruby/2.3.0/fiddle/import.rb:74:in `collect'
    from /home/jay/usr/lib/ruby/2.3.0/fiddle/import.rb:74:in `dlload'
    from /home/jay/usr/lib/ruby/gems/2.3.0/gems/opengl-bindings-1.5.3/lib/glfw.rb:421:in `load_lib'
    from /home/jay/usr/lib/ruby/gems/2.3.0/gems/mittsu-0.1.0/lib/mittsu/renderers/glfw_window.rb:5:in `<top (required)>'
    from /home/jay/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /home/jay/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /home/jay/usr/lib/ruby/gems/2.3.0/gems/mittsu-0.1.0/lib/mittsu/renderers/opengl_renderer.rb:9:in `<top (required)>'
    from /home/jay/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /home/jay/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /home/jay/usr/lib/ruby/gems/2.3.0/gems/mittsu-0.1.0/lib/mittsu/renderers.rb:1:in `<top (required)>'
    from /home/jay/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /home/jay/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /home/jay/usr/lib/ruby/gems/2.3.0/gems/mittsu-0.1.0/lib/mittsu.rb:12:in `<top (required)>'
    from /home/jay/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `require'
    from /home/jay/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `rescue in require'
    from /home/jay/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
    from ./game.rb:6:in `<main>'

game.rb is a slightly modified version of the example program from the readme. the glfw installation is fine, i can use it from both C and Ruby (through another gem). mittsu should've loaded libglfw.so from the same directory. the right way to load the lib seems to be this: https://github.com/vaiorabbit/ruby-opengl/blob/master/sample/util/setup_dll.rb#L37
so the problem is in lib/mittsu/renderers/glfw_window.rb.
when i replaced GLFW.load_lib('libglfw3.dylib', path) with GLFW.load_lib() i got a core dump. so i'd like to hear your opinion before i continue poking on my own, i'm kinda of a noob when it comes to ruby.

P.S. i couldn't run the game without manually installing pry.

When loading a multi-material OBJ file, such as male02.obj, each time a new material is encountered, the existing mesh is finished, a copy made of the vertices, and then a new mesh started. This means that connectivity information becomes more vague, as an loaded object may have multiple meshes, each with separate (albeit coincident) vertices, and a separate list of faces.

This is probably fine for rendering, so it may be a low priority issue, but in my use case where I'm trying to convert files, it means that I've lost some information, and when I output a mesh there are lots and lots of unused vertices.

I suspect the right way to solve it is for the loader to use geometry groups, as described in https://threejs.org/docs/index.html?q=buffergeom#api/en/core/BufferGeometry.groups, rather than separate meshes, but I don't know what the state of those is in Mittsu currently.

There are a number of deprecation warnings showing up in the builds.

The following deprecation warnings are prevalent:

warning: constant ::Fixnum is deprecated
Use assert_nil if expecting nil from <path to source>. This will fail in Minitest 6.

Curious if you considered building a wrapper for THREE.js via Opal a la Opal-Phaser?

(Re: Opal-Phaser itself, I know @ylluminarious has been busy with other stuff and it's not abandoned, just hasn't had our attention for a while due to project requirements.)

https://threejs.org/docs/index.html#api/geometries/RingGeometry

grep in mittsu for RingGeo finds nothing.

when trying to use Mittsu::RingGeometry:
uninitialized constant Mittsu::RingGeometry (NameError)

mittsu it does not work in WSL2 Ubuntu-18.04?

My error is: Unable to create window.

Code:

Thank you.

Hello,

Thanks for working on this awesome library! The examples have been really useful, and I've been able to hack together something that works.

Is it possible to render these scenes as an image? I couldn't find anything in the source code, and I'm not sure how to do it with OpenGL. It would be great if there was an example that rendered to an image, instead of opening the window.

This could also be quite useful for some test cases. You could render a scene to an image, and then compare the images with a perceptual hash.

Hiya,

I just tried to start playing with this great little library, unfortunately the steps lined out in the README do not lead to executable code on my Mac.

The reason seems to be that at some point, "libglfw3.dylib" has been renamed to "libglfw.3.dylib" in GLFW, maybe with the 3.2 release? Your README states that mittsu only works with 3.1 but it's not really easy to install a 3.1 via homebrew.

Is there a specific reason you need to load "libglfw3.dylib" instead of just loading ""libglfw.dylib" as opengl-bindings would do by default? In my homebrew installation they point to the same thing?

Willing to do a PR for changing this, but as my experience with this stuff is limited, I have no good grasp on the possible consequences.

I was following the directives in the README, but I can't push using:
git push origin pascalr-branch
It says
remote: Permission to jellymann/mittsu.git denied to pascalr.
fatal: impossible d'accéder à 'https://github.com/jellymann/mittsu.git/' : The requested URL returned error: 403

I have never contributed to github before. Maybe it's a stupid mistake, but I followed exactly the README.

Hi, maybe I found problem in this file: mittsu-0.3.3/lib/mittsu/renderers/opengl/textures/texture.rb :)

As you can see:
if wrap_s != ClampToEdgeWrapping || wrap_t != ClampToEdgeWrapping OR min_filter != NearestFilter && min_filter != LinearFilter outputs warning, and interpolates #{texture.source_file}, but texture is actually undefined.

I don't know what it needs to be instead of undefined texture, because of that I can't create PR with fix

I wanted to see a grid, but GridHelper isn't implemented, so I thought to draw my own lines and got into this issue:

/Users/alxx/.rvm/gems/ruby-2.4.1/gems/mittsu-0.3.0/lib/mittsu/renderers/opengl/core/object_3d.rb:25:in 'init': undefined method 'initted' for #Mittsu::LineBasicMaterial:0x007f9337593180 (NoMethodError)

Relevant code portion:

  line_material = Mittsu::LineBasicMaterial.new(color: 0x1122ff)
  geometry = Mittsu::Geometry.new
  geometry.vertices << Mittsu::Vector3.new(0,0,0)
  geometry.vertices << Mittsu::Vector3.new(20,0,0)
  line = Mittsu::Line.new(line_material, geometry)
  scene.add(line)

On Ubuntu and CentOS when trying to run example scripts I get error:
mittsu/lib/mittsu/renderers/generic_lib.rb:4:in discover': undefined method get_platform' for OpenGL:Module (NoMethodError)

After fooling around I found if I force include the opengl-bindings from home rbenv path it works without issue: (excuse my ignorance if there is a better way)
Example:
ruby -I/$HOME/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/opengl-bindings-1.6.7/lib 05_earth_example.rb

Huge fan of this repo, thank you very much for the work here. I found it perfect for interfacing to Ball Aerospace COSMOS telemetry feeds.

Platform: Linux
Ruby version: 3.0.2p107
Mittsu OpenGL Renderer 0.4.0

Running several examples like 02_geometries, 05_earth and 07_earth_normal showcases continuous memory increase.

First, I would like to thank for Mittsu. Awesome work!

I tried to poke around the code and change the MeshBasicMaterial to MeshPhongMaterial but on runtime there's no visible object presented.

I might missing something, I guess.