... as well core.matrix supports normalise, which I just reali*z*ed since I am American English. haha
On Saturday, October 19, 2013 8:05:47 AM UTC-4, Chris Gill wrote: > > I am in this boat as well, clojure + opengl, currently using lwjgl for > bindings and management. I am curious why you need float support actually, > what specific methods are you hoping to utilize this with? Currently I > create float-arrays from the loaded mesh and build the VBOs and push that > all the to card the one time, this would be done for every mesh or > combination of meshes. After that all work, for me at least, I use uniforms > to manipulate the scene and so far have planned to do this through > core.matrix to work with the uniforms-- I don't plan on using very many > lwjgl functions since much of it seems geared towards pre-opengl 3 stuff. > Performing matrix ops on 1000 objects doesn't seem out of the realm of what > core.matrix can handle-- it's using ndarrays and seems quick so far. So my > question is maybe you can skirt the issue? I don't really know your > scenario, but what version of openGL do you plan on supporting? Keep in > mind core.matrix even has some euclidean math built in such as length and > distance. > > I based this off of a c++ example so it may be wrong as of yet-- haven't > implemented as of now; here is normalize and lookat to fill in some more > functions (using core.matrix): https://gist.github.com/viperscape/7055130 > > > On Monday, September 9, 2013 9:43:12 AM UTC-4, Alex Fowler wrote: >> >> Hello! >> >> With this letter I would like to receive an answer from somebody from the >> development team (if anyone else has something to say, you're surely >> welcome :) ). >> >> I am working for a big multimedia company and recently I have been >> considering moving to Clojure as the main language of development. We have >> been doing Java and Scala before, but now when I tried Clojure and see the >> possibilities it provides, I would definitely stand for it to be our >> ground. However, while I am so satisfied with everything - the language, >> the community, the Java interop, there is still something that hinders and >> makes me linger. Namely, the lack of good support of floats and ints in the >> language. While many people would not consider it to be a huge disadvantage >> or even notice it, things are not so bright when it comes to OpenGL. >> >> The case is that OpenGL and 3D graphics hardware in general has no >> support for doubles or longs. Therefore, all libraries, all data and all >> computations are meant to be performed with floats and ints (shaders too). >> Due to the lack of good support of these data types in Clojure (for >> example, there are no ^float and ^int typehints, float and int values can >> only be typecasted to, all calculations always retain doubles and longs), >> results in too many extra typecasts, which are absolutely unnecessary and >> take too much time. So, calculations become very cumbersome, even if we do >> not take mandatory boxing into account. >> >> Considering that such kinds of calculations are usually abuntant in the >> aforementioned types of applications, the penalty grows really huge. I have >> endeavoured several discussions on the IRC to find out possible >> workarounds. Although many good proposals by many good people were made, >> aimed at improving the situation, none of them could solve the fundamental >> lack of the ability to manipulate 32bit primitive (or even boxed) data >> types. That lack renders Clojure not really suitable for heavy-load OpenGL >> applications that require somewhat extensive calculations: some kinds of >> games, simulations, generative graphics and so on. Considering how superior >> Clojure is to any other language available for JVM, that black spot looks >> especially embarrasing. And I could imagine falling back to Java for fast >> computations, just like we fall back to ASM in, say C, that is very >> undesirable and discouraging, since we want to pick Clojure for Clojure and >> it will be too cumbersome to make 50/50% Java/Clojure apps just to work >> around that design decision. >> >> Therefore, while deciding if to pick Clojure as the base for our >> development, I would like to know answers to the following questions: >> >> 1) What is the current reason for the support for these types to be >> missing? >> 2) Are there any plans for improvement of support for floats, ints and >> maybe, localized unboxed calculations? Or is there some advice on how to >> enable their support? >> 3) What is you vision for Clojure + OpenGL applications? >> 4) Is it possible to request support for floats, ints and maybe shorts >> for the language? >> 5) Is it possible to request support for localized unboxed calculations, >> like (with-unboxed ... ) and localized float-only and int-only >> calculations, like, say in special macros (with-floats-&-ints ... here go >> (+) (-) and stuff ONLY with floats/ints ... ) ? >> >> Preferably, I would like to hear the answers from somebody from the >> development team, because I have already received enough support from the >> community, on the IRC, I appreciate it, but now I have to make a serious >> choice for our company and I feel quite responsible for that. I also feel >> that these questions are very important for any specialist that works with >> OpenGL and influence Clojure acceptance for OpenGL-enabled applications >> world-wide. Thank you. >> > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
