Please bring back OpenGL1 and P3D!

James10

Please bring back OpenGL1 and P3D!

The OpenGL 2 libary continues to be buggy and limited - to the point of being unusable for more complex graphics.

Processing has evolved and improved since versions 1.21 and 1.51. And yet at this point the graphics OpenGL library continues to be major regression from the previous libraries.

As processing 1.51 becomes less usable with new 64-bit versions of Java, all of the capabilities that were part of the older libraries are going lost. Can you please make the older libraries available again in current processing versions - at least as an option?

Thank you! James

quark

Please do not double post - duplicate has been deleted

amnon

This post doesn't make any sense. The new OpenGL renderers have much more capabilities, such as shaders and PShapes.

James10

Yes, the new OpenGL renderers have some additional capabilities, but they have lost a lot of capabilites as well:

Lines and text do not look good in 3D, many types of geometries are blurred, using JOGL and the buffer utilities has become cumbersome - particularly when integrating lights, many geometries have become much slower to render, textmode(screen) is gone, beginShape/endShape geometries are buggy.

It is definitely not a win-win situation. In many cases OpenGL2 is a regression. It would be great to get the original OpenGL1 and P3D back - at least as options.

GoToLoop

As processing 1.51 becomes less usable with new 64-bit versions of Java,

If we remove its "/java/" subfolder, it's forced to use system's installed Java instead.
That can even be 64-bit JDK 8! \m/

James10

GoToLoop,

Where on mac is this "/java/" subfolder? Not in processing's package contents? On OSX 10.10 yosemite, processing 1.51 no longer runs at all:

[0] "Error: This Java instance does not support a 32-bit JVM." [1] "Please install the desired version." Using startup command: {command=command=java -d32

GoToLoop

Perhaps in Mac it's more complicated b/c in the old days, Apple had its own bundled Java, prob 32 bits!
All of a sudden, Apple abandoned both Java & Flash! And Mac owners had to install them by themselves!
All I can say is that Processing 1.5.1, for both Windows & Linux, works w/o its bundled "/java/" subfolder. >-)
And system's JDK can be 32 or 64 bits. My own P1.5.1 works w/ 64-bit OpenJDK 7 in my Lubuntu! O:-)

yasuhara_t

I would also favor the return of the original libraries.

OpenGL2 curtails many of the strengths and features of the original libraries. It has lots of bugs and runs very inconsistently across platforms and graphic cards. Particularly the low-level GL features that are necessary for highly detailed geometries are almost inaccessible. I’ve never understood why one would introduce a library that eliminates previous features and at best substitutes them with new ones.

I’ve long ago resorted to teaching with Processing 1.51. Unfortunately this limits the amount of memory available on some systems to 2GB, as the 64-bit Java can’t always be forced. Thus one has to teach Eclipse as well- which just puts an unnecessary burden on students and flattens their learning curve, and defeats the whole purpose of the simple interface in the first place.

The change to OpenGL2 certainly has some benefits over the original libraries, yet it comes with many major drawbacks.

please give us back the originals!

GoToLoop

I’ve long ago resorted to teaching with Processing 1.51. Unfortunately this limits the amount of memory available on some systems to 2GB, as the 64-bit Java can’t always be forced.

As I've mentioned, it can be forced by renaming/deleting "java/" subfolder in Windows or Linux!
Seems like Mac is the exception though! :-<

yasuhara_t

Mac is used by almost half of the students these days. There used to be a Java utility where you could specify which java version would be given preference, but processing ignored those settings anyway. As James pointed out, processing versions prior to 2.0 don't run at all with mac's latest OS. Anybody know how to resolve this?

But why not just integrate the original p3d and opengl libraries into the current version of processing, sort of as a 'hidden' option? That would solve a lot of problems and headaches.

PhiLho

IIRC, somebody (quark?) made the old P3D mode into a library, so you can still have it.
For OpenGL, it isn't so simple, but I don't expect the developers to go back: it would increase the burden of maintenance.

amnon

Indeed, having so many renderers dilutes the focus of the developers. I believe this was the main reason for the choice to cut down on the number of renderers. At some point, there will probably be a new GLGraphics library that will allow for more advanced OpenGL controls, similar to the previous GLGraphics library for older Processing versions.

Another strategy may be to create some small runnable code examples of problems or bugs you are running into and seeing if A) people on the forum can help find a solution (personally I haven't encountered the structural problems with lines/geometry you mention) or B) these problems can be fixed in subsequent releases of Processing. Either way would also be beneficial for others (ad A sharing knowledge and ad b fixing bugs & adding capabilities).

Please do realise that developer time is limited. In fairness advanced OpenGL controls may be beyond the current focus of the developers, however reporting bugs is always useful (you can only fix bugs that are known). Also, if you have advanced OpenGL knowledge, you may even help fix some issues that remain.

I am just pointing out some different ways to look at this and perhaps other strategies to move forward.

quark

IIRC, somebody (quark?) made the old P3D mode into a library

Not me, but would be interested in knowing whether its true and how to get hold of it ...

amnon

@quark: see http://forum.processing.org/one/topic/old-p3d-renderer-for-processing-2.html

James10

To summarize the posts above:

1. OpenGL2 doesn’t run well on many (lower cost) laptop computers, is still very buggy, is slower in many cases, and doesn’t allow advanced OpenGL controls.

2. The suggested answer for those that need these functionalities is to continue to use Processing 1.51 with the original GLGraphics library, or for those that don't need OpenGL, to use bustup's P3D libary.

3. Processing 1.51 will run with 64-bit Java on Windows and Linux by removing certain subfolders. On Mac, it seems the 64-bit version can’t be forced, i.e. so one is limited to 2GB. Worse yet, it doesn’t run at all on current system OS-X 10.10.

So maybe the next step would be for somebody to create a version of 1.51 that let’s you choose which Java version to use (preferably 64-bit), and - for OS-X - perhaps even comes bundled with a Java version that works. This would ensure that everybody can continue to have access to original GLGrpahics library’s functionality.

Are there any developers reading this that could respond?

amnon

That summary is biased. It seems you only hear what you want to hear. These kind of posts ("the old was better, the new has bugs etc.") were made a lot when Processing 2 was just released. Now that some time has passed, we already see much less of them. In time the nostalgia for 1.5.1 will fade away, like it did for 1.2.1. and the ones before that. In the meantime, the developers are already working on Processing 3.

The next step is not to move backwards, but to move forwards. Perhaps the first step is to get a new computer (why do people expect to have advanced, modern OpenGL capabilities on cheap, old laptops?). The negativity towards the current OpenGL renderers is unjustified. Once again, if you have bugs, file them here.

James10

amnon, to 'just get a new computer' seems like an out-of-touch piece of advice. maybe you can get a new computer, maybe i can, but lot of the users and students in less developed countries don't have the resources to just buy a new computer. and certainly not just because somebody changed a library.

nor do people expect to have 'modern openGL capabilities' on old laptops. i think they just hope to maintain the capabilities they once had.

if you would step back, stop thinking in terms of 'forward vs backward tropes', and neutrally assess the advantages and disadvatanges of OpenGL1 and OpenGL2, then you'll find that OpenGL2 has many benefits over OpenGL1. But OpenGL1 has just as many, very distinct, benefits over OpenGL2. i think the wish to sustain these advantages is not at all an unreasonable one.

but maybe you only want to hear what you want to hear?

quark

It is true that there are a lot of people who can't afford new computers but then it is unrealistic for a limited number of volunteer developers to maintain old code.

Attempting to keep backward compatibility requires a huge commitment from the development team that could be used to keep abreast of new developments. There is always the danger that people abandon Processing because it becomes 'out-of-date'.

In situations like this it is a balancing act and someone is always going to be disappointed.

amnon

Everybody can maintain the capabilities they had, because the old versions of Processing are still available. My point is that the efforts of developers are (justifiably) invested in the current / newer versions and chosen renderers of Processing. And that the most constructive contribution is to support these efforts (share knowledge, submit or fix bugs, etc.) instead of looking at past versions. Once again, the versions as they once were are still available.

Also, as the push is made towards newer technologies (for example it's now possible to customize PShader to use geometry and tesselation shaders), there will at some point be a trade-off at the lower end (for example, older graphics cards will no longer be able to cope). That may be a harsh reality, but it's not exclusive to Processing.

You are a bit late in advocating the benefits of a neutral assessment of the respective renderers, as this thread has been anything but that from the get-go. If these problems / disadvantages are so distinct, you should provide (in separate threads) small & runnable OpenGL2 code examples that show the issues you are facing. Perhaps people on the forum can show a more optimized solution or if it turns out these are actually bugs (as there always have been and always will be), they can be filed as concrete issues for the developers to fix.

James10

'Everybody can maintain the capabilities they had'. this is exactly the point - many people can not!

processing 1.51 or earlier will not run on the latest OS-X. see the very first post.

amnon

So now you are saying the main point was about older Processing versions not running on OSX? First of all, OSX wasn't even mentioned in your first post. Second, that is an OSX problem, not a Processing problem. If 'newer versions' are the main cause of all your problems, then you should update nothing and just retain the status quo as everything used to be.

yasuhara_t

@quark: There is always the danger that people abandon Processing because it becomes 'out-of-date'. I completely agree with this. Yet I view it from a different perspective. Consider this scenario for a moment:

A competitive university in coastal China. Eastern China may have surpassed the US in terms of HDI indicators, Pisa scores, infrastructure, and whatever else, but in terms of real GDP and disposable income, there continues to be a large gap. Consequently, at least a third of the students in class have older laptops that don’t support the graphics with Processing 2.0 or 3.0. Income inequality is almost as high as in the US, so you also have a handful of privileged students with shiny new macs.

For the former group, doing the class in Processing 1.51 allows them to use graphics. Yet for the latter group, anything before 2.0 will no longer run on their OS at all. One option is to use two versions in parallel, and leave it to the students to adjust their code, hunt for the correct libraries, work out the peculiarities and bugs, and just try make the software work. But this is difficult (blocked internet access to processing forums, and often also to the entire site), time consuming, and frustrating. An alternative is to switch to Eclipse. This works, yet slows their learning and the limits fun and motivation that comes with having nearly instant successes. It defeats the simplicity of Processing.

In this scenario, the students no longer go ahead and write quick and interesting programs, but instead spend a lot of time trying to figure out why their programs won’t run properly. And increasingly often, the problem is not with their code.
Students and teachers from the other thousand less competitive universities in China look towards the competitive ones in Eastern China, and they may find a ambivalent acceptance of Processing rather than a energetic, enthusiastic one. This is the danger I see about people potentially abandoning Processing that quark speaks about. The risk lies in Processing becoming the antithesis of what it once was.

I understand the importance of staying abreast of new developments, and I salute the Processing developers for doing so. Without exactly this curiosity and drive, there would never have been Processing in the first place. Yet I also think it’s important to periodically stop and evaluate to see what really works, rather than to reflexively defend the very latest iteration or to hope for soon-to-be fixed bugs. Most importantly, I think one needs to ensure that the core functionality of Processing still works. That all students and users - regardless of platform and operating system version and whether the computer cost $2000 or $500 - can properly use this language. This is what is at stake.

quark

@yasuhara_t

I understand everything you say but the Processing development team don't have the resources to maintain older versions.

There is a lot of exciting and graphical things that can be done with Processing using the default Java2D renderer. :)

PhiLho

Note: there is no Processing 1.51. Not sure where you saw that. There is a 1.5.1 version, though...

Funnily, I agree with both parties...

On one hand, it is too bad to exclude old computers from accessing 3D at all. My not-so-old computer, with a rather average (at the time, probably outdated today) GPU can display the OpenGL required by Processing 2+, but is very slow to start up a 3D sketch.

Now, it is somehow the rule of the software world: buy a modern game, there is a chance it won't start on your teeny weeny computer, too... :-) Annoying, but understandable.
It takes lot of resources to maintain n versions of a software, including finding workarounds to low-end computers, or accepting to have ugly graphics for your application (with resulting potential bad rep...).
A big game studio won't do it, then what about a small team of volunteers that isn't specifically paid for their work on Processing?

I dislike the choices made, but I bet the developers themselves disliked them, but they had to do them to be able to maintain, grow and evolve the software.

Now, if some individuals are motivated enough (and have free time!), the source code of Processing 1.x is available: it can be resurrected, improved, evolved, etc.
That's lot of work...

clankill3r

I'm motivated to work on processing 3.0 :) Starting in 10 minutes.

GoToLoop

As we are already starting to see omens like this 1:
http://forum.processing.org/two/discussion/8810/how-does-processing-set-it039s-renderer

the idea of forking Processing 1.5.1 is starting to get tempting! >:)

clankill3r

boolean wtf = processing151 > processing2X; // true

tlecoz

Hello ! I'm sorry but I almost never used Processing 1.5.1 and previous versions.... I just would like to know : what was the difference ? How could it work faster ? (it doesn't sound logical to me)

GoToLoop

(it doesn't sound logical to me)

Even though Processing 2 brought advanced OpenGL features, it also removed some Processing 1 1s: :O

• P2 lost renderers: fast P2D & soft P3D. Now P3D is the same as OPENGL & P2D is a fake 2D OpenGL!
• Lost deployment ready-for-the-web Applet unified ".jar" file.

Now Processing 3 removes Applet inheritance, bringing incompatibilities, diverting development focus from more important things w/ no real performance gain! ~X(

clankill3r

Is there any discussions on github about PApplet? I would really like to read the motivation behind it. And while where at that, I'm even more interested in the conversation about the idea of having the precompiler taking care of the chosen renderer.

GoToLoop

That was already decided by that close-knitted small council. And the work for it is almost done! :-&
From now on, we'll have to deal w/ that trail of incompatibility bugs! I-)
IMO, only a Processing 1.5.1 fork could maintain old features while incorporating new 1s! o->

tlecoz

Hello GotoLoop, Clankill3r !

"Now P3D is the same as OPENGL & P2D is a fake 2D "

It's very consistent with what I experienced : if I manage the vertex-call by myself, I obtain the same result with P2D & P3D.

I understand what you mean but what is the OpenGL problem exactly ? I'm a bit noob with that kind of stuff, almost everything I recently did in 3D was based on OpenGL (and for me it's the best of the best, but if I listen to you, I 'm starting to think it's maybe not the best of the best.... Is it or not ?! :) )

Actually, I really / trully think that performance issue doesn't come from the kind of renderer (maybe it is, I don't know the other) but mainly come from the amount of data sent during the draw call... Because for each vertex processing send 37 values to the shader and it's HUGE ! In the case of 2D-sketches, 10-15 values should be enought for most of scenario.

clankill3r

What 37 values does processing send?

tlecoz

X,Y,Z,U,V,NormalX,NormalY,NormalZ, etc.... I don't know exactly................. I guess there are some infos concerning the stroke, specific values for lights (for spotlight for example) etc...

Using 37 values per vertex does not only represent a huge amount of data in the buffer but it also means that the shader-side must be over-complex even if you only want to draw a plane with a solid-color fill.

I suppose that it contributes to be slower - than what OpenGL can do -

James10

@tlecoz - This was one of the nice things about the graphics in the original OpenGL library: it was very easy to use the low-level buffer utils to pass only the vertex data that was required. Very fast, simple and easy to combine with GLU, lights, etc.

Now that unfortunately become impossible - at least on Mac. Unlike on Windows, Processing versions 1.5.1 and before will not start up on Mac OS-X at all anymore. Many programs written in 1.5.1 or 1.2.1 can thus no longer run, and new programs can no longer take advantage of all the great features of the original OpenGL library.

Has anybody found a solution to this? Is there a way to run 1.5.1 on Mac, perhaps by pointing it to a different JDK?

monkstone

What about installing linux? Then you can choose what software you want to install

GoToLoop

http://forum.processing.org/two/discussion/8731/can-not-run-my-old-sketches-with-processing-1-5-1

monkstone

GotToLoop why emulate when can dual boot, or better if your hardware is old (and say you've got windows XP) just replace it with a suitable distro (say Mint), you don't even need to wear a hair shirt, just turn off the eye-candy.

GoToLoop

• W/ dual boot we either have 1 OS or the other at a single time.
• W/ emulation we have both OSes!
• Been about 2 years I use Linux only.

clankill3r

I think I switch Linux some day soon as well. If I boot my mac then it uses 5g ram when not even a single application is opened! Each year the software is getting worse.

GoToLoop

If I boot my mac then it uses 5GB ram when not even a single application is opened!

Some internal system software is probably defective! You should reformat and reinstall some OS! 8-|