PDA

View Full Version : What is LightWave CORE?



oliversimonnet
05-07-2010, 11:56 AM
hello everyone
i no i have asked this question before in anther thread, but i still don't relay understand what LightWave CORE is, or is going to be (sorry :s )
so i thought i would let the question of "what is LightWave CORE?" have its own thread

is it a new 3D program that is like going to replace LightWave.
or is it like an expansion for LightWave?

thank you in advance.

walfridson
05-07-2010, 12:00 PM
Hm how long will it take before this turns into a "what should core be" thread :)

From what I read on the feature list and dreamed off, it's what you love in lw but miss in maya...

edit: haha I kind of did it myself..

oliversimonnet
05-07-2010, 12:06 PM
aa so technically they are merging modeler and layout or something like that?
if they do that it might end up relapsing LightWave.

Kuzey
05-07-2010, 12:14 PM
is it a new 3D program that is like going to replace LightWave.
or is it like an expansion for LightWave?


Yes, it is a totally new program that will replace Lightwave...but, not right now, sometime in the next few years.




or is it like an expansion for LightWave?


It's an expansion in name only...the idea of Lightwave will live on...but not as we know it.

Kuzey

rkpdesign
05-07-2010, 12:24 PM
Can someone kindly help me?

I have time again to devote to learning LW again. I came from a 3DMax background.

I am a CORE member, but what I want to know is, if I am just beginning should I focus only on LW HC or 9.6.1? Are they similar enough that 9.6.1 tutorials will be understandable in HC?

Thanks for any information. I can be a bit slow, but honestly, I am getting a little confused.

Thanks again!

oliversimonnet
05-07-2010, 02:12 PM
Yes, it is a totally new program that will replace Lightwave...but, not right now, sometime in the next few years.

aaaa ok, do you think lightwave will become less used as the years go by (after CORE)

It's an expansion in name only...the idea of Lightwave will live on...but not as we know it.

Kuzey

aaa ok cool
so it will be the end of an era lol

Kuzey
05-07-2010, 02:31 PM
aaa ok cool
so it will be the end of an era lol

And hopefully, the new era will be a better one. That is, if Newtek does it right :)

Kuzey

Silkrooster
05-07-2010, 10:33 PM
should I focus only on LW HC or 9.6.1? Are they similar enough that 9.6.1 tutorials will be understandable in HC?

LWHC and 9.6.1 are similar. If you want more information it would be wise to post in the core forums, where we can go into more details.

oliversimonnet
05-08-2010, 06:23 AM
And hopefully, the new era will be a better one. That is, if Newtek does it right :)

Kuzey

aaaa lets hope so :)
mmm, well i see no reason y they wouldn't do it right

Kuzey
05-08-2010, 06:41 AM
There is a few things that scare me at the moment :)

One, being the new viper. It's always on, even as you rotate your scene or object....it looks like a big mess.

There are 3 snap tools...when one should do and there are four ways to add primitive objects to your scene....what's that all about :D

Kuzey

oliversimonnet
05-08-2010, 09:37 AM
There is a few things that scare me at the moment :)

One, being the new viper. It's always on, even as you rotate your scene or object....it looks like a big mess.

There are 3 snap tools...when one should do and there are four ways to add primitive objects to your scene....what's that all about :D

Kuzey

mm ye the viper think might be a bit anoyin, but i other ways useful
and what do you mean by 4 ways to ad primitives? :s

Ernest
05-08-2010, 09:53 AM
There are 3 snap tools...when one should do and there are four ways to add primitive objects to your scene....what's that all about :D

Kuzey

How can you tell the drag tool to snap as soon as it hits an edge in the background as opposed to a vertex if you only have one snap toggle?

SERHELL
05-08-2010, 10:25 AM
any news about the tools of animation tools in particular characters in core?

I hope that core come with something revolutionary for the animation in every way. I do not want to belittle the other tools, but I especially am interested only in the tools of animation and render_ and I'm sure many people also. I worry about the fact that not mentioned anything about the tools of animation, this is a very important if you want to make a competitive program in the market.

sorry my english

Kuzey
05-08-2010, 11:33 AM
mm ye the viper think might be a bit anoyin, but i other ways useful
and what do you mean by 4 ways to ad primitives? :s

Lets see:

1- the same way you do now in 9.6, click sphere button and then mouse click and drag.

2- click a different sphere button and the sphere with be automatically created at the origin and at the size of 1m x 1m x1m...I think.

3- there's the gesture tool, swipe your mouse in a circular fashion and you have a sphere.

4- There's one more...the line tool or pen tool or maybe something else.

Kuzey

Kuzey
05-08-2010, 11:53 AM
How can you tell the drag tool to snap as soon as it hits an edge in the background as opposed to a vertex if you only have one snap toggle?

You use a key to toggle as you drag....lets say the "e" key is for edges, "p" key for points and the "f" key for faces.

You have a face selected, and as you drag it...it will snap to nearby faces under the mouse cursor. In this case, you don't need to press the "f" key because it's working in the same mode...face to face snapping.

Now, if you want to snap the face to a point or edge then you press the "P" or "e" keys as you drag.

Sounds pretty simple to me...but then again I'm not in the Hardcore program.


Kuzey

oliversimonnet
05-08-2010, 01:14 PM
Lets see:

1- the same way you do now in 9.6, click sphere button and then mouse click and drag.

2- click a different sphere button and the sphere with be automatically created at the origin and at the size of 1m x 1m x1m...I think.

3- there's the gesture tool, swipe your mouse in a circular fashion and you have a sphere.

4- There's one more...the line tool or pen tool or maybe something else.

Kuzey

aaa ok lol i get it now lol

do yhu think that every one will stop using LW and use LWHC in the end or do you think that LW will go on

(actualt that all depends on how good LWHC is dont it?)

Kuzey
05-08-2010, 01:51 PM
aaa ok lol i get it now lol

do yhu think that every one will stop using LW and use LWHC in the end or do you think that LW will go on

(actualt that all depends on how good LWHC is dont it?)

I think there will be people using LW 9.6 for sometime....even after Core is a complete app.

LWHC is just a temporary app...until Core can stand on it's own feet. It's not supposed to exist on it's own. Anyway, it's missing one feature that 9.6 doesn't have, but Core does...the ability to handle huge polygon counts. That would have made LWHC a very appealing upgrade for many users...but that requires a total rewrite and would be a waste of time.

For most people, it all depends on how good Core turns out...I'm hoping it's going to be super cool :hey:

Kuzey

oliversimonnet
05-08-2010, 02:02 PM
aaa ok ok
ye i hope it will be cool to :)

Andrewstopheles
05-08-2010, 02:03 PM
no news yet on character tools in CORE - you can view the features document on the CORE webpage on this bsite to see what CORE v.1.0 will be

Ernest
05-08-2010, 08:05 PM
You use a key to toggle as you drag....lets say the "e" key is for edges, "p" key for points and the "f" key for faces.

In other words, you still need the three of them. You would just use the shortcut key instead of clicking on the button. That makes sense for every tool, but also having a "visual" button can be useful, especially while learning.


You have a face selected, and as you drag it...it will snap to nearby faces under the mouse cursor. In this case, you don't need to press the "f" key because it's working in the same mode...face to face snapping.

Now, if you want to snap the face to a point or edge then you press the "P" or "e" keys as you drag.

Sounds pretty simple to me...but then again I'm not in the Hardcore program.

Kuzey

It is simple but, you mean keeping the key pressed all the time that you need snapping? If I have to drag 300 points, snapping them to an edge, it seems less work to click on the Snap Edges button once than to keep the E key pressed during all that dragging. It is simple but also seems a bit more hardworky to me. If you want to snap to points and faces but not edges, you'd keep the P and F pressed all that time?

If you mean just tapping the E, F, P to toggle then it's not much different than having the three buttons with a shortcut key assigned.


Anyway, it's missing one feature that 9.6 doesn't have, but Core does...the ability to handle huge polygon counts.

You're saying that very matter-of-factly, considering that the new features of LWHC haven't been published.

Kuzey
05-09-2010, 04:26 AM
In other words, you still need the three of them. You would just use the shortcut key instead of clicking on the button. That makes sense for every tool, but also having a "visual" button can be useful, especially while learning.



It is simple but, you mean keeping the key pressed all the time that you need snapping? If I have to drag 300 points, snapping them to an edge, it seems less work to click on the Snap Edges button once than to keep the E key pressed during all that dragging. It is simple but also seems a bit more hardworky to me. If you want to snap to points and faces but not edges, you'd keep the P and F pressed all that time?

If you mean just tapping the E, F, P to toggle then it's not much different than having the three buttons with a shortcut key assigned.



You're saying that very matter-of-factly, considering that the new features of LWHC haven't been published.

The problem is I'm not in the hardcore program so this is the first time I'm reading the snap tool is interactive...eg click snap tool and then drag points, faces etc.

How do other programs handle the snap tools, do they have 3 different snap tools as well?? The whole idea of Core was to consolidate tools and not have multiple tools doing the same thing. As I see it, Newtek is still keeping that old LW way of doing things.

Ideally, you would have one button and as you drag, whatever is under or near the mouse cursor gets highlighted...points, edges or faces. Once the correct item gets highlighted, you release the mouse click and it snaps to it. Now, if the mesh is dense and it's hard to highlight the item you want to snap to...then, you can press a key to narrow down the options...making it easier to locate your destination points, edges or faces.

Another way, is to be able to select points, edges and faces at the same time without changing modes. So first, you select some faces and then select the points or edges you want them to sap to and click the snap tool.

Actually...thinking about it, these two options in the one tool would be super cool and super fast.

Kuzey

hrgiger
05-09-2010, 05:59 AM
Another way, is to be able to select points, edges and faces at the same time without changing modes. So first, you select some faces and then select the points or edges you want them to sap to and click the snap tool.



We have a tool in CORE that allows editing of points, edges, and faces without changing modes. Can't go into detail about that though.

As far as snapping, take LWCAD for example. It's snapping engine is aces. All of LWCAD tools work with snapping and the snap panel has many options which go far beyond Lightwave. You don't have to use shortcut keys or enable snapping, you make changes in a global snap panel and tell it where you want snapping to work. http://www.wtools3d.com/manual/manual3/assets/video/snap_panel/snap_panel.htm

Kuzey
05-09-2010, 06:30 AM
We have a tool in CORE that allows editing of points, edges, and faces without changing modes. Can't go into detail about that though.

Interesting indeed...I hope the snap tool will have access to that information....should make things easier :hey:



As far as snapping, take LWCAD for example. It's snapping engine is aces. All of LWCAD tools work with snapping and the snap panel has many options which go far beyond Lightwave. You don't have to use shortcut keys or enable snapping, you make changes in a global snap panel and tell it where you want snapping to work. http://www.wtools3d.com/manual/manual3/assets/video/snap_panel/snap_panel.htm

Yes, it does look cool...but it seems like a lot of clicking of to get stuff done...first you need to turn off the NEAR button and then activate the END button etc. I wonder, if it would be better if those were always on and you just released the mouse button on the highlighted item and it's done with.

I do love the ruler snap and angle snap...I can see those having their own buttons for sure....or some kind of option in a panel type setting.

Kuzey

Kuzey
05-09-2010, 06:34 AM
PS...I presume Core won't have that many options with the 3 snap tools?

Kuzey

hrgiger
05-09-2010, 06:38 AM
Yes, it does look cool...but it seems like a lot of clicking of to get stuff done...first you need to turn off the NEAR button and then activate the END button etc.

No, you can leave on all the modes if you want, Viktor was just turning them off so you could see each one individually. For instance, when I use LWCAD, I generally leave on point, near, end and projection snap because they're the ones I use most often.

Too early to say much on CORE snapping and again, can't really go into much detail anyway.

Kuzey
05-09-2010, 07:50 AM
No, you can leave on all the modes if you want, Viktor was just turning them off so you could see each one individually. For instance, when I use LWCAD, I generally leave on point, near, end and projection snap because they're the ones I use most often.

Too early to say much on CORE snapping and again, can't really go into much detail anyway.

I'm sure, having them all on would become difficult in a non architectural high density mesh. All the LWCAD examples were done on flat shapes so it would be interesting to see if it works on organic objects too.

I wonder....how the other major apps handle snapping :)

As always, Thanks for the information :thumbsup:

Kuzey

hrgiger
05-09-2010, 08:11 AM
I'm sure, having them all on would become difficult in a non architectural high density mesh. All the LWCAD examples were done on flat shapes so it would be interesting to see if it works on organic objects too.



Yes, it's often not desirable to leave all snapping modes on just because you may be trying to snap to one thing and it can 'fight' you on which object it actually snaps to when components are close together like in a denser mesh. Center snapping is one of those modes that is usually good to turn on only when you need it because you might be trying to snap to an intersection or end point and it keeps popping you to the center of a segment or poly, that gets old real quick. Having said that, all the snapping modes are incredibly useful when you need them.

Snapping in LWCAD would work on ogranic objects too. In fact, I can think of a few good instances where you could use it for that. One would be scaling characters. You could use LWCAD's scale snap tool to scale a character to specific Height and it allows you to scale in 1D, 2D or 3D. It's not made for that specifically, but LWCAD has uses even for the non-CAD types too.

Kuzey
05-09-2010, 01:29 PM
One thing I noticed:

Cool, I didn't know VPR is always on... in fact I highly doubt it since I have core right in front of me and VPR is just another Viewing mode. So if I switch the viewport to a normal OpenGL one... no "mess". :) Or I misunderstood "always on"...



No, I don't mean switching viewport modes. Check the vpr video, where the tanker is rotated..as it turns, vpr is trying to render the scene and you are left with a big mess...that's what I mean by it's always on. That is not cool and it's not professional.

What should happen in those cases, is that the viewport switches to OpenlGL mode until you stop moving or rotating objects, then and only then should vpr kick back into action.

Kuzey

Kuzey
05-09-2010, 01:45 PM
Yes, it's often not desirable to leave all snapping modes on just because you may be trying to snap to one thing and it can 'fight' you on which object it actually snaps to when components are close together like in a denser mesh. Center snapping is one of those modes that is usually good to turn on only when you need it because you might be trying to snap to an intersection or end point and it keeps popping you to the center of a segment or poly, that gets old real quick. Having said that, all the snapping modes are incredibly useful when you need them.

Snapping in LWCAD would work on ogranic objects too. In fact, I can think of a few good instances where you could use it for that. One would be scaling characters. You could use LWCAD's scale snap tool to scale a character to specific Height and it allows you to scale in 1D, 2D or 3D. It's not made for that specifically, but LWCAD has uses even for the non-CAD types too.

Options are always a good thing..but LWCAD is not a full program, that's the point I was trying to make. It can work outside of what it's designed for, but it might be limited...that is the impression I'm getting.

Kuzey

Lightwolf
05-09-2010, 01:57 PM
That is not cool and it's not professional.
That's called progressive rendering and is a feature. Especially as it keeps refining if you don't move the mouse.

Cheers,
Mike

Kuzey
05-09-2010, 02:04 PM
That's called progressive rendering and is a feature. Especially as it keeps refining if you don't move the mouse.

Cheers,
Mike

Ah ah..You say feature, I say bug :)

But seriously, that should taken into account. At the moment, I see vpr as half complete in that regard.

Kuzey

Lightwolf
05-09-2010, 02:07 PM
Ah ah..You say feature, I say bug :)
You might want to forward that remark to Steve Worley and Luxology as well as all those people writing nifty GPU renders currently ;)

Cheers,
Mike

Lightwolf
05-09-2010, 02:11 PM
Ah ah..You say feature, I say bug :)

As a minor side note, because I keep reading it quite often.
A feature that doesn't work as expected by one of more users is not a bug.

A bug is something that doesn't work as specified or designed by the developers (unless it is something serious like a crash, but that goes into the same category anyhow).

Cheers,
Mike

Kuzey
05-09-2010, 02:13 PM
You might want to forward that remark to Steve Worley and Luxology as well as all those people writing nifty GPU renders currently ;)

Cheers,
Mike


Seems like everyone is following each other doesn't it :hey:

Just beacuse people are used to it with fprime...doesn't make it right or best practice.

Kuzey

Lightwolf
05-09-2010, 02:16 PM
Just beacuse people are used to it with fprime...doesn't make it right or best practice.
Oh, FPrime wasn't the first... Steve Worley use the same idea in the early 90ies for his essence textures and that was revolutionary.
It's not only geometry changes that are meant to re-trigger a new render by the way.

Cheers,
Mike

probiner
05-09-2010, 02:18 PM
Indeed it could be cool to have the IPR "overlaying" the regular OGL viewport when this one is idle (being VPR=IPR over OGL), since it is quite messy before you can see clearly what are you pointing at and will force you to use another viewport with OGL for navigation porpuses only.

But call it a bug? Naahh... It's doing what is supposed to do. How does Modo and Fprime perform when you change stuff or move the camera? But in those cases you never rely on one viewport for both navigation and render preview.

Some sort of wireframe over the render preview would be great too. Anyway, whatever makes it more effective, as possible =)

Cheers

Kuzey
05-09-2010, 02:20 PM
As a minor side note, because I keep reading it quite often.
A feature that doesn't work as expected by one of more users is not a bug.

A bug is something that doesn't work as specified or designed by the developers (unless it is something serious like a crash, but that goes into the same category anyhow).

Cheers,
Mike

I see it as a bug because of this bit
Especially as it keeps refining if you don't move the mouse.

From my point of view...that stops you from working, unless you take a coffee break and let the render finish:)

Kuzey

Kuzey
05-09-2010, 02:30 PM
Og, FPrime wasn't the first... Steve Worley use the same idea in the early 90ies for his essence textures and that was revolutionary.
It's not only geometry changes that are meant to re-trigger a new render by the way.

Cheers,
Mike

I remember seeing Cresshead's video on Max 3d OpenGL lights or whatever it was. That has an example of the viewport updating only after Cresshead stopped rotating the view. Someone out there is doing it right....at least, that's the way it looked to me :)

Kuzey

zarti
05-09-2010, 02:33 PM
I'm sure, having them all on would become difficult in a non architectural high density mesh. All the LWCAD examples were done on flat shapes so it would be interesting to see if it works on organic objects too.

CAD programs do not get that dense in mesh quantity like poly_based modeling apps; because of Nurbs&Co.

when you mention organic shapes, i do not think you are referring to cases where you want to find / snap the tangent_line or quadrant_point from the top of a characters ear ... :D


What should happen in those cases, is that the viewport switches to OpenlGL mode until you stop moving or rotating objects, then and only then should vpr kick back into action.

it might look like a screensaver and distracting ( imo ) considering how often we navigate over the subject ...

if it is fast, it could be really cool in full time vpr-mode !

Kuzey
05-09-2010, 02:52 PM
It's completely misunderstanding the main reason for that feature and it's not designed to be the main viewport mode for modeling and navigating.




Some of them have very nice ideas*, but switching from rendering to OGL was never one of them... for good reason. ;)


Well, when you are modeling and navigating, vpr would start rendering from scratch anyway...so, why not delay it until the modeling and navigating has stopped for a bit or so. If it's not designed for that, which is fine, then it should not work in those conditions.

Kuzey

Kuzey
05-09-2010, 03:04 PM
CAD programs do not get that dense in mesh quantity like poly_based modeling apps; because of Nurbs&Co.

when you mention organic shapes, i do not think you are referring to cases where you want to find / snap the tangent_line or quadrant_point from the top of a characters ear ... :D


Right...I managed to use the wrong term..."poly_based modeling" would have been better :D

I get the feeling that Cores snap tools are more placement tools. Select one face of a cube and have the whole object move, while the selected face snaps to a point or whatever....that kinda a thing.

Kuzey

Kuzey
05-09-2010, 03:15 PM
No, that's when you simply don't switch to VPR as a viewing mode. :) The beauty of a unified app. BTW: Why would you want restrictions in core this early? :confused:

That's the way they used it in the demo video :)

Switching between viewing modes might be simple but it can become laborious if you need to do it all the time. Having vpr delayed while modelling or navagating is a better option in my view.

Kuzey

Kuzey
05-09-2010, 03:21 PM
EDIT: Sorry - I got it now! It's max variation on LWs viewport "bounding box threshold". It's called "Adaptive degradation". Has nothing to do with a renderer. If the card is not fast enough it removes polys. Was just fancy OpenGL then. Look forward to similar stuff in core. :thumbsup:

I'm on my iPod so it'll be hard to locate it, it's the one with coloured lights and and low res figures. Where the lights and their shadows looked liked they were baked but weren't

Kuzey

Cageman
05-09-2010, 03:22 PM
I see it as a bug because of this bit

From my point of view...that stops you from working, unless you take a coffee break and let the render finish:)

Kuzey

Uh?

Not sure what to say about your stance regarding how Interactive Renderers work. What exactly is it that would stop you from working? Turn it off if you are distracted by it, if that is what you are getting at?

Kuzey
05-09-2010, 03:30 PM
Uh?

Not sure what to say about your stance regarding how Interactive Renderers work. What exactly is it that would stop you from working? Turn it off if you are distracted by it, if that is what you are getting at?

No...if you want a preview vpr render then you have to make sure you don't move your mouse...or it starts all over again. I was going by something Mike said in that post.

Unless I got it wrong??

Kuzey

hrgiger
05-09-2010, 03:34 PM
I saw another interactiver renderer for Max that turned off when you rotated the view and I really hated it.

Moving your mouse wouldn't trigger the renderer to start over, only changing your view or changing scene/object properties.

Lightwolf
05-09-2010, 04:08 PM
I remember seeing Cresshead's video on Max 3d OpenGL lights or whatever it was. That has an example of the viewport updating only after Cresshead stopped rotating the view. Someone out there is doing it right....at least, that's the way it looked to me :)

It's a matter of preference - certainly no bug though. I assume the preview spheres in LW are doing it the wrong way as well then if you switch them to realtime. What a bummer, all this wasted effort in implementing that ;)

Cheers,
Mike

Lightwolf
05-09-2010, 04:10 PM
No...if you want a preview vpr render then you have to make sure you don't move your mouse...or it starts all over again. I was going by something Mike said in that post.

Unless I got it wrong??

You did. I mean _while_ navigating. Obviously not when you're not navigating.
I.e. you press alt to tumble, click lmb and move the mouse and the render goes blocky to refresh the changed view. But then it refines that unless you move the mouse more (while you're still tumbling).

The idea (and principle) is to react and preview all changes as quickly as possible, even if it's blocky at first.

Cheers,
Mike

Cageman
05-09-2010, 04:28 PM
No...if you want a preview vpr render then you have to make sure you don't move your mouse...or it starts all over again. I was going by something Mike said in that post.

Unless I got it wrong??

Kuzey

Oh..

Ok... seems you kind of got it wrong. :) As long as you do not change anything that would affect the objects, lighting or rendersettings, or navigate in the viewport that holds VPR, you should be fine. If you want to spend some time refining a render for better judging your changes or whatever, you can still surf the web or do pretty much anything while waiting for the progressive render to reach the level you need.

Kuzey
05-09-2010, 10:46 PM
You did. I mean _while_ navigating. Obviously not when you're not navigating.
I.e. you press alt to tumble, click lmb and move the mouse and the render goes blocky to refresh the changed view. But then it refines that unless you move the mouse more (while you're still tumbling).

The idea (and principle) is to react and preview all changes as quickly as possible, even if it's blocky at first.

Cheers,
Mike

Ah ah....you should have added the "navigating" bit in the first place...but no harm...no foul :hey:

I still see it as a bug, you aren't supposed to navigate in the vpr mode but you can and if you do, you get a fine mess.

That to me is a bug...at the very least they should have an option to disable vpr in such situations.

Kuzey

Kuzey
05-09-2010, 10:53 PM
And that's why I already said elsewhere that the video is not a really good one. ;)

But...it's better to see that now than buy Core and be shocked later :)

I was thinking of copying that section of the video and uploading it to the web...and say, check out the greatest preview renderer out there :hey:

Kuzey

Lightwolf
05-10-2010, 03:06 AM
Ah ah....you should have added the "navigating" bit in the first place...but no harm...no foul :hey:

You started it ;)

Check the vpr video, where the tanker is rotated..as it turns, vpr is trying to render the scene and you are left with a big mess...that's what I mean by it's always on.



I still see it as a bug, you aren't supposed to navigate in the vpr mode but you can and if you do, you get a fine mess.
Actually, you are supposed to. But, it's certainly not a viewport mode you'd work in when modelling, certainly one to keep open when modelling though.

That to me is a bug...at the very least they should have an option to disable vpr in such situations.
Well ,if you navigate in VPR when showing nothing would be even worse, as you get no feedback. And if you navigate in another viewport then it's no issue anyhow.

Also, it's still not a bug only because you think it is... :D

Sheesh, kids are spoiled nowadays. ;)

Cheers,
Mike

oliversimonnet
05-10-2010, 06:04 AM
is it not possible to turn of the VPR?

zarti
05-10-2010, 06:12 AM
is it not possible to turn of the VPR?

yes. you can turn it off.

probiner
05-10-2010, 06:16 AM
lol oliver. VPR is just one of the new cool features of CORE. All these "issues" raised make you want to turn it off now? :D

Well, its "just" a Viewport rendering style, so you can change it.

Today you can change the View Type with keys, but not the Render Styles, which could be nice. (and it would bring Kuzey peace :D)

Cheers

oliversimonnet
05-10-2010, 09:48 AM
lol oliver. VPR is just one of the new cool features of CORE. All these "issues" raised make you want to turn it off now? :D

Well, its "just" a Viewport rendering style, so you can change it.

Today you can change the View Type with keys, but not the Render Styles, which could be nice. (and it would bring Kuzey peace :D)

Cheers

ye i think its cool to
its just some people think it might be an issue so i was just wondering lol

i hope core wont be to diff to LightWave, that way we wont need so many new tuts :)

Hieron
05-10-2010, 10:16 AM
*many posts regarding VPR and a "mess" and "bug"*



And I had been living under the impression that it was a mighty handy feature to get a near realtime view of changes! Turns out it was all a bug..

DBMiller
05-10-2010, 12:48 PM
Check out the new announcement from The Deacon. More info to come.

Kuzey
05-10-2010, 03:21 PM
And I had been living under the impression that it was a mighty handy feature to get a near realtime view of changes! Turns out it was all a bug..

Yes...you are right this is not a bug...check out the video :neener:

Kuzey

Hieron
05-10-2010, 03:37 PM
Your point?

For starters, apparantly you never worked with a similar feature before. Second, I think it is not particularly wise to judge the "bugginess" of a "feature" on a specific scene which is jam packed with polygons on purpose to show responsiveness.

If it doesn't look very interesting to you, and you prefer OpenGL, well... it's already there! omg. For people that do appreciate a progressive renderer like that, VPR exists.

But my guess is you really enjoy using the VPR alot, and use it and Fprime for years and are just trolling. And as usual with me, being succesfull. Or at least, I hope you are. For you.

probiner
05-10-2010, 04:19 PM
Yes...you are right this is not a bug...check out the video :neener:

Kuzey
It's a (V)Preview(R) is like when you were in a video editing project and you had a side television screen to have the final result feeling and not just the computer monitor feeling.
Fprime, Modo work like that, side preview screen, to have the final feeling without having to make a final render.
If Core can also have a better navigation options like the one you mentioned, or simply displaying a toggable wireframe, overlaying the render calculations, better. But for now it's doing it's job and kicking arse :neener:

Kuzey
05-10-2010, 11:31 PM
Your point?

For starters, apparantly you never worked with a similar feature before. Second, I think it is not particularly wise to judge the "bugginess" of a "feature" on a specific scene which is jam packed with polygons on purpose to show responsiveness.

My point is it's not complete. I said before, it doesn't make it right just because everyone is going the same thing..after all, we all want Core to be better than the others...don't we??

Are you actually saying it works in realtime as you navigate, as long as the object is simple...say something like a cube??

Can you make a video of that and upload it?



If it doesn't look very interesting to you, and you prefer OpenGL, well... it's already there! omg. For people that do appreciate a progressive renderer like that, VPR exists.

Wrong.....you are still not getting it.



But my guess is you really enjoy using the VPR alot, and use it and Fprime for years and are just trolling.

And here I thinking you were the one trolling, jumping into a discussion just to make a quick point...did you even read the whole thread?

Kuzey

Kuzey
05-10-2010, 11:35 PM
It's a (V)Preview(R) is like when you were in a video editing project and you had a side television screen to have the final result feeling and not just the computer monitor feeling.
Fprime, Modo work like that, side preview screen, to have the final feeling without having to make a final render.
If Core can also have a better navigation options like the one you mentioned, or simply displaying a toggable wireframe, overlaying the render calculations, better. But for now it's doing it's job and kicking arse :neener:

Ah ah...yes, vpr is really cool and I like were it's heading, but it still needs a few polishing touches. That's what I'm trying to say :)

Kuzey

Cageman
05-11-2010, 12:06 AM
Kuzey,

It seems you are just very unaware of how these things work and why they work the way the do. As for CORE, it allready has an upper hand compared to other similar solutions; turn any viewport into a VPR. All other implementations of similar renderers all requiers floating window somewhere (FPrime, Modo, Rendition for Mental ray).

Could you be more precise in exactly what it is you are refering to as a bug? We allready know that selected polys are not staying highlighted in VPR, but that is something the devs are aware of and will add in later builds.

Kuzey
05-11-2010, 12:26 AM
Kuzey,

It seems you are just very unaware of how these things work and why they work the way the do. As for CORE, it allready has an upper hand compared to other similar solutions; turn any viewport into a VPR. All other implementations of similar renderers all requiers floating window somewhere (FPrime, Modo, Rendition for Mental ray).

Could you be more precise in exactly what it is you are refering to as a bug? We allready know that selected polys are not staying highlighted in VPR, but that is something the devs are aware of and will add in later builds.

I wasn't talking about the selected polys...I'm sure they'll fix that sooner or later.

In the edited video I uploaded, you can see vpr is useless when navigating a scene or rotating objects etc....it's not fast enough to render at realtime and you are left with a pixelated mess until you stop.

That's what I'm getting at...it shouldn't try to render a scene in those situations, it should just stop or pause and when the user has stopped navigating...it should start rendering again.

It just needs a little finishing touch...that's all.


Kuzey

Gumby22don
05-11-2010, 01:29 AM
In the edited video I uploaded, you can see vpr is useless when navigating a scene or rotating objects etc....it's not fast enough to render at realtime and you are left with a pixelated mess until you stop.

That's what I'm getting at...it shouldn't try to render a scene in those situations, it should just stop or pause and when the user has stopped navigating...it should start rendering again.
Kuzey

Pretty sure that the behaviour we see in the video is someone very familiar with their scene, navigating and able to understand the blocky image because they know what they are working with, while those of us viewing for the first time aren't clicking and dragging the mouse, and don't know what the user was trying to do with the viewport, so it feels a little more disjointed. Its like being the person driving a car, or being in the passenger seat- one feels a lot more in control, and thus arguments ensue.

I think if you were the one controlling, you could just pause half a second longer, and have as clear a view as you like before manipulating the viewport again. If the VPR was a camera viewport, you would most definately want to be able to change the view within that viewport, not be limited to using other viewports just because that one is VPR...

Don
have a great day

Kuzey
05-11-2010, 03:16 PM
I guess I didn't get it...but seems simple to me. If you have an option to make a preview render in a viewport and you can't interact with your scene, then something seems wrong....to me anyway.

It's a viewport after all, not a non interactive previewer. If you want that...then it should be a floating panel like the rest and be done with it. So the problem for Newtek is to either make it just a normal previewer or make it more useful...by allowing the user to interact with the scene.

Here is the video I was talking about:

http://www.youtube.com/watch?v=_Tk3Fh3DZl8

You can see, as Cresshead rotates the scene...the changes he made...only update once he stops rotating the scene via the time line. This is what I think should happen with vpr.

Then you can have vpr always turned on in a viewport and model, navigate as much as you want within the same viewport. In my view, it'll be more powerful feature...but then I'm just thinking outside the square :D

Nice example Oliver...it's much better than how vpr does it...but still not quite there :thumbsup:

Kuzey

Lightwolf
05-11-2010, 03:28 PM
It's a viewport after all, not a non interactive previewer.
It's both.

If you want that...then it should be a floating panel like the rest and be done with it.
This is something that Core should address anyhow.
There should be no difference between docked or floating panels and certainly no limits to the number or location of viewports (which now already contain more than just modelling views).

Cheers,
Mike

Myagi
05-11-2010, 03:29 PM
To be fair, that 3DS thing isn't the same thing as a preview render. The VPR is essentially using the actual render engine to quickly produce something somewhat similar to a final render. What the 3DS thing shows is real-time HW GL/D3D rendering with real-time shaders and postprocessing effect (kind of like a game). That type of rendering will also be available (to some degree).

The reason it does "update" the image after it stops rotating is because what it displays is the same GL/D3D render, only with post processing passes and such applied after it stops. Whereas the VPR renders the scene through the software rendering engine, and displays the results, which isn't the same GL/D3D rendering as what you see in normal viewports.

With that said I agree that some kind of visual clues like a wireframe overlay during a orbit/pan operation would be helpful, so you aren't moving around blindly in heavier scenes (or having to stop all the time and wait to see if you panned to where you want).

Kuzey
05-11-2010, 03:35 PM
It's both.

This is something that Core should address anyhow.
There should be no difference between docked or floating panels and certainly no limits to the number or location of viewports (which now already contain more than just modelling views).

Cheers,
Mike

Mike...you and your technicalities :hey:

It might be both...but, at the moment it looks like two different concepts thrown in together without thought.

Kuzey

Lightwolf
05-11-2010, 03:37 PM
Here is the video I was talking about:

http://www.youtube.com/watch?v=_Tk3Fh3DZl8

You can see, as Cresshead rotates the scene...the changes he made...only update once he stops rotating the scene via the time line. This is what I think should happen with vpr.

You do realize that this is completely different technology, right?

And the D3D/OpenGL viewport updates as he scrubs anyhow, but it also never refines to anything better either.
Which wouldn't work with either technology either, as D3D/OpenGL can't be interrupted while they process a frame (which is one reason while viewports can feel sluggish while operating on them, they have to fully redraw whatever you do, and with all the geometry they have to display once triggered).

As a trivia side note: Before Modeler supported OpenGL the viewports were drawn in software (CPU code, only wireframe, LW 5.6) - one advantage of that system was that navigating extremely heavy meshes was surprisingly quick as the drawing could just abort where it was at the moment if the user decided to navigate to another position. So this is actually an advantage that progressive renderers have at the moment (I've also seen cases where the coarse FPrime preview was faster than what the viewport tried to display in OpenGL in Layout).

I wonder if all this confusion actually comes from the fact that NT are the first to mix an interactive viewport with a progressive renderer as a view option, something that's not available in an other app so far.

Cheers,
Mike

Lightwolf
05-11-2010, 03:40 PM
Mike...you and your technicalities :hey:

It might be both...but, at the moment it looks like two different concepts thrown in together without thought.

Well, modo allows for that (for example) and it's extremely cool.
And yes, it is two concepts thrown together... except that you're so far the only one who doesn't think it's cool ;)

I.e. Most see this as: 1+1=4 whereas your take seems to be: 1+1=0 ;)

Just wondering, have you ever had the chance to work with a progressive renderer?

Cheers,
Mike

Kuzey
05-11-2010, 03:43 PM
To be fair, that 3DS thing isn't the same thing as a preview render. The VPR is essentially using the actual render engine to quickly produce something somewhat similar to a final render. What the 3DS thing shows is real-time HW GL/D3D rendering with real-time shaders and postprocessing effect (kind of like a game). That type of rendering will also be available (to some degree).

The reason it does "update" the image after it stops rotating is because what it displays is the same GL/D3D render, only with post processing passes and such applied after it stops. Whereas the VPR renders the scene through the software rendering engine, and displays the results, which isn't the same GL/D3D rendering as what you see in normal viewports.


Cool info...I was just comparing the delay in updating..not the types of rendering....but it's good to know Core will get something like it in the future :thumbsup:



With that said I agree that some kind of visual clues like a wireframe overlay during a orbit/pan operation would be helpful, so you aren't moving around blindly in heavier scenes (or having to stop all the time and wait to see if you panned to where you want).

Now...we're cooking :D

Kuzey

Chris S. (Fez)
05-11-2010, 04:01 PM
When adjusting lights and such a delay in the preview would kill the interactivity. Newtek could add a Kuzey navigation mode where the viewport renders only when you have stopped orbitting/zooming/panning.

Similar to Layout's bounding box threshold settings...

Lightwolf
05-11-2010, 04:02 PM
Similar to Layout's bounding box threshold settings...
Or the Preview options in the Surface Editor (which also affect VIPER) ;)

Cheers,
Mike

Chris S. (Fez)
05-11-2010, 04:08 PM
Or the Preview options in the Surface Editor (which also affect VIPER) ;)

Cheers,
Mike

Cool! My favorite response to a feature request, however humbling...:D

Lightwolf
05-11-2010, 04:21 PM
Cool! My favorite response to a feature request, however humbling...:D
:D That is actually something I looked at again yesterday...

Cheers,
Mike

probiner
05-11-2010, 04:50 PM
As for CORE, it allready has an upper hand compared to other similar solutions; turn any viewport into a VPR. All other implementations of similar renderers all requiers floating window somewhere (FPrime, Modo, Rendition for Mental ray).
Not Modo.But you still need 2 windows.
http://www.architosh.com/features/2006/reviews/modo/images/800_modo_202_liverender.gif

Indeed if CORE could have a bit more options with a toggable overlaying wireframe, or what Lightwolf said, it would leave others behind =)
Being possible for example to select a light, move it around, knowing where it is without having to wait and having a preview of it, all in same window.
Hotkeys for for Render Styles would work too.


Anyway... Chucks knows it all :D

Software Developer's Dilemma: The better the new feature, the more feature requests it will generate. - C. Baker :)

Hieron
05-11-2010, 05:10 PM
My point is it's not complete. I said before, it doesn't make it right just because everyone is going the same thing..after all, we all want Core to be better than the others...don't we??

Are you actually saying it works in realtime as you navigate, as long as the object is simple...say something like a cube??

Can you make a video of that and upload it?


*sigh* yes, a cube is the only possible thing, you are right. Happy?

So, you are seriously asking for an example, years after the Fprime introduction into the market? I already pointed towards the Fprime example movies. I can't be bothered to make some for you. Because you can't be assed to look it up, here is a link:
http://www.worley.com/Media/animations/fprime/FP3_Massive.mov

Check about 2/3 of the way. That is a 500k poly's "cube" for ya, quite some years ago. See how he moves crap about and within a second the shot makes good sense? Some scenes it is even faster, some scenes it is slower. But that can be a massive workflow enhancement, not to have any "delay".

Perhaps you never needed such a thing, fine.



Wrong.....you are still not getting it.


Sure, whatever.



And here I thinking you were the one trolling, jumping into a discussion just to make a quick point...did you even read the whole thread?

Kuzey

Yes, the whole part of some bloke without a clue on how handy a progressive renderer can be. Without any interest to look up good exampkles, and basing all his views on some example video that makes perfect sense to others and was over the top on purpose. Did you even listen to that video while he states that each ship has about 0.5M polys with serious GI in the scene? and in your posted one there are quite alot of them? So you're seeing a very heavy scene, which is very far from "a cube", which is still workable if you're familiar with that scene?

While I agreed that funky things can be done as an optional overlay, the point is that that is not a bug and in many circumstances a very workable situation. As many pointed out here. But sure, that must be "thrown together without much thought", devs are very well known for not giving a crap and just tossing stuff in.

Why do I even bother.

Lightwolf
05-11-2010, 05:12 PM
Why do I even bother.


Eliza: Can you elaborate on that?


:D

Cheers,
Mike

cgisoul
05-11-2010, 11:28 PM
hmmm

Kuzey
05-11-2010, 11:54 PM
*sigh* yes, a cube is the only possible thing, you are right. Happy?

So, you are seriously asking for an example, years after the Fprime introduction into the market? I already pointed towards the Fprime example movies. I can't be bothered to make some for you. Because you can't be assed to look it up, here is a link:
http://www.worley.com/Media/animations/fprime/FP3_Massive.mov

Check about 2/3 of the way. That is a 500k poly's "cube" for ya, quite some years ago. See how he moves crap about and within a second the shot makes good sense? Some scenes it is even faster, some scenes it is slower. But that can be a massive workflow enhancement, not to have any "delay".

Perhaps you never needed such a thing, fine.





Sure, whatever.



Yes, the whole part of some bloke without a clue on how handy a progressive renderer can be. Without any interest to look up good exampkles, and basing all his views on some example video that makes perfect sense to others and was over the top on purpose. Did you even listen to that video while he states that each ship has about 0.5M polys with serious GI in the scene? and in your posted one there are quite alot of them? So you're seeing a very heavy scene, which is very far from "a cube", which is still workable if you're familiar with that scene?

While I agreed that funky things can be done as an optional overlay, the point is that that is not a bug and in many circumstances a very workable situation. As many pointed out here. But sure, that must be "thrown together without much thought", devs are very well known for not giving a crap and just tossing stuff in.

Why do I even bother.

I wonder why you bother as well....you still are way off...seems like that's a normal thing for you.

There is no rotating of meshes or scene in that video, you and I are talking about different things...I hope you understand that?? Another thing, you can't move objects in the fprime floating panel but you can in vpr...two different things.

The idea about the delay is..it only kicks in if you are moving or rotating meshes or viewports...not when you are moving lights etc. Are we on the same page yet???

Kuzey

cgisoul
05-11-2010, 11:56 PM
Okay, after pages and pages of what Vpr is and tech comparison, so what is CORE really all about? Modeler and Layout will go away and CORE will replace all with its new technology?
How far are we for the delivery of the first version?

Kuzey
05-12-2010, 12:03 AM
Well, modo allows for that (for example) and it's extremely cool.
And yes, it is two concepts thrown together... except that you're so far the only one who doesn't think it's cool ;)

I.e. Most see this as: 1+1=4 whereas your take seems to be: 1+1=0 ;)

Just wondering, have you ever had the chance to work with a progressive renderer?

Cheers,
Mike

Actually, since I still regard vpr as beta, but I can see the possibilities...I look at it as follows:

Now: 1+1=1

Future: (1+ user interactivity)+(1+ more user interactivity) = you bloody beauty...the best thing since slice bread...ever :hey:

And no, I haven't used progressive renderer...I guess I still have fresh eyes/perspective on the issue :D

Kuzey

probiner
05-12-2010, 12:22 AM
Actually, since I still regard vpr as beta, but I can see the possibilities...I look at it as follows:

Now: 1+1=1

Future: (1+ user interactivity)+(1+ more user interactivity) = you bloody beauty...the best thing since slice bread...ever :hey:

And no, I haven't used progressive renderer...I guess I still have fresh eyes/perspective on the issue :D

Kuzey
:ohmy: for the last time. The Core video uses the VPR in a way that normally previewers are not used:
- It's normally a side window. Users don't rely on it to navigate in the scene, but just to have a look at how it will be when rendered.
- It's normally a smaller version of the actual render, not that big has in the CORE video, so it's less demanding and refreshes faster.

Kuzey
05-12-2010, 12:32 AM
:ohmy: for the last time. The Core video uses the VPR in a way that normally previewers are not used:
- It's normally a side window. Users don't rely on it to navigate in the scene, but just to have a look at how it will be when rendered.
- It's normally a smaller version of the actual render, not that big has in the CORE video, so it's less demanding and refreshes faster.

Yes, I get all that.

What I'm saying is...why limit it so it's "normal" like the others...when it can be so much better???

edit: Next you guys might say, lets take out the high polygon feature in Core, because we aren't used to it in the normal LW...I'm talking about progress not stagnation.

Kuzey

wsi
05-12-2010, 12:36 AM
How far are we for the delivery of the first version?
Very far. And even more far away from a unified, single app.

cgisoul
05-12-2010, 01:25 AM
Very far. And even more far away from a unified, single app.

I would assume give it 2 years to become a complete unified single app.
No?

Hieron
05-12-2010, 01:51 AM
Perhaps Modo is a good example to go by, then it will take a fair few years... 5 years sounds optimistic to me as well, unless some serious talent and resources can be used.

That sounds like a long time to lean on LWHC and similar though..

pooby
05-12-2010, 01:52 AM
It is worth considering that, before it was released, 2 years of design and initial coding had gone into CORE.
It has been out almost a year and a half in 'Hardcore'.

so thats 3 and a half years to get to the current state,

The notion that CORE will be full app in 2 years is very unrealistic.

I agree that maybe in 7 years, if it were Newteks priority CORE could have most of what Softimage, Max and Maya have now.

I would estimate that in 2 years time, much of the teething problems will have been ironed out and the general tools will be starting to be used in preference to Classic Lightwave.
I imagine that, if we are lucky we will start to see the character animation system being introduced.

Cageman
05-12-2010, 01:58 AM
Cool info...I was just comparing the delay in updating..not the types of rendering....but it's good to know Core will get something like it in the future :thumbsup:
Kuzey

http://www.newtek.com/lightwave/images/profiles/imagesimage/newsletter/04_2010/jroth/Buddha2.png

That is a screenshot from April Newsletter where COREs viewport is using Realtime CG-shaders and posteffects. The screenshot is showing SSAO (the same type of AO you see in game-engines) and Bloom. Notice the FPS-counter in top left of the image.

EDIT: Just to be clear here; that image shows OGL-viewport which should not be confused with VPR. As others have pointed out, VPR is an interactive version of the renderengine.

cgisoul
05-12-2010, 02:13 AM
I should have been more specific. When I said 2 years, I certainly wasn't mentioning a full complete app. My mistake, what I wanted to say is, in around 2 years time to have Layout and Modeler joint together as a full complete app from the classic LW.

colkai
05-12-2010, 02:51 AM
I would assume give it 2 years to become a complete unified single app.
No?

I'd say that was, at best, overly optimistic now that LW is a 3-app suite that seems to intimate CORE being part of LWX, sounds like buying time so folks get used to using 3-apps.

How this would differ say from using LW9.6 with collada output to a.n.other 3rd party product I dunno and folks can do that already.


what I wanted to say is, in around 2 years time to have Layout and Modeler joint together as a full complete app from the classic LW.

I still think that is highly unlikely, as Pooby said, much time has been spent on this already and even now, it seems some still in HC think it is not "useable".

No good having new toys when the fundamentals are not solid, but alas, that is something history has shown has a track record of occurring and then some.

Kuzey
05-12-2010, 12:32 PM
http://www.newtek.com/lightwave/images/profiles/imagesimage/newsletter/04_2010/jroth/Buddha2.png

That is a screenshot from April Newsletter where COREs viewport is using Realtime CG-shaders and posteffects. The screenshot is showing SSAO (the same type of AO you see in game-engines) and Bloom. Notice the FPS-counter in top left of the image.

EDIT: Just to be clear here; that image shows OGL-viewport which should not be confused with VPR. As others have pointed out, VPR is an interactive version of the renderengine.

Thanks Cageman...I forgot about that image. I wonder how looks when navigating in realtime. :D

Kuzey

Lightwolf
05-12-2010, 01:52 PM
Thanks Cageman...I forgot about that image. I wonder how looks when navigating in realtime. :D

Probably exactly the same as it's OGL - but then again it's also not an interactive renderer either...

Oranges and... well, tomatoes ;)

Cheers,
Mike

Kuzey
05-12-2010, 02:06 PM
Probably exactly the same as it's OGL - but then again it's also not an interactive renderer either...

Oranges and... well, tomatoes ;)

Cheers,
Mike

I do believe Cageman mentioned that :hey:

I was just wondering how it compared to the Max one...if there were delays in updates or it was realtime etc.

Kuzey

Myagi
05-12-2010, 02:28 PM
as seen from the shot it updates at 75 fps :)

There is no effect there that would require some kind of extra processing that requires a delay ala Max. SSAO is works on an image buffer, not dependent on geometry complexity like real AO.

Kuzey
05-12-2010, 02:37 PM
as seen from the shot it updates at 75 fps :)

There is no effect there that would require some kind of extra processing that requires a delay ala Max. SSAO is works on an image buffer, not dependent on geometry complexity like real AO.

Cageman mentioned "Realtime CG-shaders and posteffects". So, I thought the post effects would have caused a little delay.

But seeing it action is better than just a screen grab...hehe.

Kuzey

Myagi
05-12-2010, 02:44 PM
Yeah, but in this case SSAO (as mentioned in the newsletter) is a real-time effect. In fact it's used in several games too :)

Kuzey
05-12-2010, 02:47 PM
Ah...cool stuff :D

Kuzey

hrgiger
05-12-2010, 07:37 PM
SSAO: http://en.wikipedia.org/wiki/Screen_Space_Ambient_Occlusion

oliversimonnet
05-13-2010, 09:23 AM
hello.
has any one here subscribed to HC yet?

oliversimonnet
05-13-2010, 09:58 AM
lol aa ok
and me i haven't
do we hafto pay 400+ pounds a year?
or is it just 400+ to join?
im planing on joining at some point.
just tryin to get to understand it more be fore i do
that is y i opened this thread :)

Kuzey
05-13-2010, 10:52 AM
Probably everyone in this thread except Kuzey... :D

Yeah...wasn't it a total of 1000 members...tops??

But I'm a fan of Core :hey:

Kuzey

colkai
05-13-2010, 12:49 PM
hello.
has any one here subscribed to HC yet?

Subscribed, then unsubscribed. :p

oliversimonnet
05-14-2010, 06:21 AM
Subscribed, then unsubscribed. :p

y did you unsubscriber?

colkai
05-14-2010, 08:54 AM
Multiple reasons really, mainly, I'd expected the focus to be on modelling from the get-go as that was what all the hype was about and it appeared to me that once again, when it came down to it, the focus was on other things like physics and rendering.
I felt that the likelyhood of it actually being a modeller that would be "all that" was slim, especially given statements being made by certain people. Concerns voiced were given a "suck it up" reply and that for me was the final straw, I'd paid up front and things, for me personally, were "not as advertised".

Of course, other peoples mileage varies and there are quite a few folks who are deliriously happy with what has been presented and how it has presented, just I am not one of them.

This said, if Chuck and Rob had been the drivers from the get-go, I couldn't say for sure I'd of still of opted for a refund, maybe I would of, maybe not as it is possible things may have gone somewhat differently.
I know some who were on the edge of opting out are holding back simply because Rob N Chuck are now 'driving'. My experience, whilst not unique, is different to others.

When all is said and done, if you have cash you don't mind blowing on a "wait and see" situation, it's a personal choice, this will be the only upgrade I have EVER refunded and previously I always pre-paid on good faith, many still will.

oliversimonnet
05-14-2010, 12:09 PM
aaaaa ok
i see :)

Nemoid
05-16-2010, 02:48 AM
Open GL features and VPR are 2 different things, don't undestand how some people can confuse them. The fact that NT is adding navigation and other possibilities within thr VPR is actually awesome. Even Modo has some degree of this, you can drop objects within the previewer and it recognizes their position so that yopu can place them in the scene, and other stuff.

Open GL is good. as we can see in several 3DS Max videos, you reach some level of similarity of a render, navigate the scene, select model, animate etc. BTW to work flawlessly and smoothly with lights, textures and more features turned on, the app has to be optimized to work with large scenes. More often you activate those features upon need, but as the scene gets more complex you may need tu turn something off. The appearence in the viewport is more similar to what you can get in game engines (and i guess very useful for game production), but its different from final render. It also usually depends heavily onto your GPU. No good videocard, forget good responsiveness.

What you get with something like VPR and FPrime, is different. Even at highly pixellated resolution, you get the final look of the render, first at a low resolution, then, as it refines, at a good res, but light and look of the image are right from a rendering POV, since the start.
As seen in the videos , VPR has to be enhanced regarding performance and speed, but this is very probably even related to render speed in CORE now. It is also a matter of options, You could have different options like in Modo regarding the quality of the rendering for VPR (draft mode, turn off some render features,(not maps) and so on, and this obviosly reflects on responsiveness of the preview system, just like it happens for render speed if you disable some features.
BTW, i agree with the fact that when navigating the scene , VPR could disable some rendering features, and so show some wireframe over the mesh (if possible technically) also to allow better selection from within the VPR rather than doing that in the viewport, and to get better performance and interaction.
I think its all a matter of time, and optimizations of this system which has to become fast with heavy scenes, that's all.

Obviously, a great app would have all those 2 features, both good Open GL features, AND something like VPR. I think in this field NT is doing quite well, it all depends on enhancing and empower those features.

Kuzey
05-16-2010, 03:36 AM
Open GL features and VPR are 2 different things, don't undestand how some people can confuse them. The fact that NT is adding navigation and other possibilities within thr VPR is actually awesome.

I haven't confused anything...I know they are two different things. I just want vpr to have a delay feature when rotating meshes or scenes. There is no need for vpr to be working during those situations...it doesn't actually help anyone or make sense...since, the view is temporary and it's still changing and what not.

PS...I'm talking about meshes/navigating scenes here...not moving lights in a static scene etc.



BTW, i agree with the fact that when navigating the scene , VPR could disable some rendering features, and so show some wireframe over the mesh (if possible technically) also to allow better selection from within the VPR rather than doing that in the viewport, and to get better performance and interaction.
I think its all a matter of time, and optimizations of this system which has to become fast with heavy scenes, that's all.


Yes...vpr is great at what it does, but it can be better....much...much better. I see it as a first/second draft, not something that is near feature complete...which is the impression I'm getting from some people.

Kuzey

Nemoid
05-16-2010, 04:11 AM
ah ok now i can understand better your reasons. Well, i think some sort of delay if technically possible would be totally aswesome, as well a huge performance enhancement. as i said it needs to have also some wireframe possibility if NT wants to make it efficient for scene management without having to work into another viewport.
Actually, there are 2 different ways of working with a VPR. Old way is working in open GL viewports and see preview either into a floating viewport or within one of the viewports as well.

Another way , the one in which CORE is heading, is having the possibility to interact into a deeper way with VPR , select things and work in it too if you want, wich requires other enhancements as you have pointed out, to give the user better performance and experience.

the whole problem is always in responsiveness. of a given system. :thumbsup:

As it is now, VPR seems not fast enough in handling large scenes, but this should improve as time passes. It's surely not a complete feature for now.

One thing i would like to point out is in how important is to have such a system within LW.
Currently, FPrime, allows not only preview render, but , mostly important, the possibility to resume rendering. As you surely know this means you can set the quality of rendering of your animation, render it, and then resume it afterwards and this is very good for production purposes. You can provide in small amount of time a rough quality animation which has just the same athmosphere an lighting of the final one. Then go ahead and resume it till final quality rendering.

Problem is that FPrime doesn't see all things whithin in old Lw, so it isn't useful for ALL the situations.

What CORE is heading to provide instead, is a system using the internal rendering engine to provide a FPrime-like functionality, and especially if in the near future they will implement bucket rendering, it will be possible to resume render in it as well, with the advantage that the rendering will see everything: lights, maps, GI, shaders, hairs, instances...
In this sense , the system should become way more than a preview render, both regarding interaction, and rendering features.

Open GL instead will be of great help during animation. Its highly important especially for animation purposes. Often in quite all app, animators work with the less options activated possible, to speed up app interaction, and animate faster. They even work with optimized blocky meshes just to get very fast responsiveness so they nail down movements, and only afterwards they work on deformations. Open GL tho is very useful in several cases, for example when you rig characters, to test out them and work with weight maps, and more, and also you can faster provide animatics where you focus basically on framinf, movements time spacing, not always the look of the render, but a good look is awesome to have as well.

Its clear that those 2 system compenetrate a bit, offering different solutions to similar problems. Some users would like to work with Open GL on steroids, other users would like to have a rendering preview in serious steroids. Me i want both !! :D:D

Kuzey
05-16-2010, 04:12 AM
Here is the idea in funny code form...from a previous thread:


If object.manipulation(rotate, scale, movement) = false or scene.manipulation(zoom, rotate, move camera) = false then

VPR.update now!!!

else

Viewport.shading = smooth shading // so we can see what we are doing while zooming/rotating/scaling etc. etc.

end if

Kuzey

Kuzey
05-16-2010, 04:43 AM
ah ok now i can understand better your reasons. Well, i think some sort of delay if technically possible would be totally aswesome, as well a huge performance enhancement. as i said it needs to have also some wireframe possibility if NT wants to make it efficient for scene management without having to work into another viewport.
Actually, there are 2 different ways of working with a VPR. Old way is working in open GL viewports and see preview either into a floating viewport or within one of the viewports as well.

Another way , the one in which CORE is heading, is having the possibility to interact into a deeper way with VPR , select things and work in it too if you want, wich requires other enhancements as you have pointed out, to give the user better performance and experience.

the whole problem is always in responsiveness. of a given system. :thumbsup:

As it is now, VPR seems not fast enough in handling large scenes, but this should improve as time passes. It's surely not a complete feature for now.

One thing i would like to point out is in how important is to have such a system within LW.
Currently, FPrime, allows not only preview render, but , mostly important, the possibility to resume rendering. As you surely know this means you can set the quality of rendering of your animation, render it, and then resume it afterwards and this is very good for production purposes. You can provide in small amount of time a rough quality animation which has just the same athmosphere an lighting of the final one. Then go ahead and resume it till final quality rendering.

Problem is that FPrime doesn't see all things whithin in old Lw, so it isn't useful for ALL the situations.

What CORE is heading to provide instead, is a system using the internal rendering engine to provide a FPrime-like functionality, and especially if in the near future they will implement bucket rendering, it will be possible to resume render in it as well, with the advantage that the rendering will see everything: lights, maps, GI, shaders, hairs, instances...
In this sense , the system should become way more than a preview render, both regarding interaction, and rendering features.

Open GL instead will be of great help during animation. Its highly important especially for animation purposes. Often in quite all app, animators work with the less options activated possible, to speed up app interaction, and animate faster. They even work with optimized blocky meshes just to get very fast responsiveness so they nail down movements, and only afterwards they work on deformations. Open GL tho is very useful in several cases, for example when you rig characters, to test out them and work with weight maps, and more, and also you can faster provide animatics where you focus basically on framinf, movements time spacing, not always the look of the render, but a good look is awesome to have as well.

Its clear that those 2 system compenetrate a bit, offering different solutions to similar problems. Some users would like to work with Open GL on steroids, other users would like to have a rendering preview in serious steroids. Me i want both !! :D:D

Haha...and I was starting to think that all Hardcore members were going feral....btw....no harm or insult intended. It just seems like people want to attack those not in the group for fun sometimes.

I'm not sure how Newtek will handle those situations...wireframe overlay or smooth shading while navigating etc...but maybe, there should be a user option/preference. I so hope they come up with a solution :hey:

Ooooh...resuming renders would be so cool as well :thumbsup:

Kuzey

Nemoid
05-16-2010, 05:00 AM
here is the idea in funny code form...from a previous thread:



Kuzey

lol.

Hieron
05-16-2010, 06:10 AM
...it doesn't actually help anyone or make sense...since, the view is temporary and it's still changing and what not."
Kuzey


"doesn't actually help anyone"

There are quite some cases when navigating a scene in OpenGL makes little sense (poly counts, set up of lights (GI) etc) when a "temporary view" is great and works out well.


In many posts people have said they could see the positives of an option to overlay OpenGL (wires, shaded) just before the VPR kicks in after x amount of seconds after moving.
But don't go and call these same people feral, because they are just pointing out that "temporary view" is not a bug nor "doesn't help anyone".

sheesh.

You could just have said "I never used a VPR or progressive renderer in my life, but wouldn't it be nice to have the option to see OpenGL first while navigating and VPR just after?"
Everyone would agree and all would have been done in about 3 posts. But you needed "bug", "no use", "works only on a cube". Sure call it fun to talk that way.. nice comm. skills.

Kuzey
05-16-2010, 07:34 AM
"doesn't actually help anyone"

There are quite some cases when navigating a scene in OpenGL makes little sense (poly counts, set up of lights (GI) etc) when a "temporary view" is great and works out well.

So you're saying the edited clip I uploaded was just fine and it should work that way?? I would have thought OpenGL would have been faster when navigating and rotating...compared to the the temporary and barely started render of the vpr...yes...no??



In many posts people have said they could see the positives of an option to overlay OpenGL (wires, shaded) just before the VPR kicks in after x amount of seconds after moving.



Not really, again, many people just said it should not work that way...eg not be interactive...you just leave it on and for get about it. Only later some people got what I was saying. You are still off btw, I'm saying the delay is during moving not "x amount of seconds after moving". The delay would be too long at that stage.



But don't go and call these same people feral, because they are just pointing out that "temporary view" is not a bug nor "doesn't help anyone".

sheesh.


I stand by it. I called people feral...because, they resort to personal attacks and cheap shots(some hardcore members)...does that not sound familiar to you??




You could just have said "I never used a VPR or progressive renderer in my life, but wouldn't it be nice to have the option to see OpenGL first while navigating and VPR just after?"
Everyone would agree and all would have been done in about 3 posts. But you needed "bug", "no use", "works only on a cube". Sure call it fun to talk that way.. nice comm. skills.

I believe I have....but not from the start, as it really shouldn't matter if I used fprime or not. A good idea is a good idea and fprime is the past and vpr should be the future. When I showed the 3d max clip, I was talking about one thing (the delay) and you guys jumped in asking if I knew the difference between that renderer and a progressive renderer.

It was quite funny actually....I was starting to think this was a forum of accounts, talking about tax numbers than creative people talking about the creative process/tools :D

Not being in Hardcore, I can only go by what people tell me...that is not my problem. If you aren't sure what I'm on about, then ask for a clarification, don't presume what I'm talking about and then proceed to attack me...thank you very much!

And just when the discussion was heading in the right direction...I guess that was too much to hope for :hey:

Kuzey

Lightwolf
05-16-2010, 07:39 AM
So you're saying the edited clip I uploaded was just fine and it should work that way?? I would have thought OpenGL would have been faster when navigating and rotating...compared to the the temporary and barely started render of the vpr...yes...no??

Yes, and... no. As I mentioned a lot earlier talking about FPrime. I've seen cases where FPrime started a render after loading a scene way before any of the OpenGL views were ready, and I've also seen the same when scrubbing through animations.


When I showed the 3d max clip, I was talking about one thing (the delay) and you guys jumped in asking if I knew the difference between that renderer and a progressive renderer.
Actually, the difference between an OpenGL viewport and a progressive renderer.

Cheers,
Mike

Hieron
05-16-2010, 08:10 AM
A good thing came from this thread at least. NT has the code now to implement it! :)
On to the rest of "what is Lightwave Core?"

Kuzey
05-16-2010, 08:15 AM
Btw...that's old code, I'm sure it needs some updating :hey:

Kuzey

Hieron
05-16-2010, 08:20 AM
As long as they also implement:

"If user.feral=active || object.manipulation(rotate, scale, movement) = false || scene.manipulation(zoom, rotate, move camera) = false then

VPR.update now!!!

else

Viewport.shading = smooth shading // so we can see what we are doing while zooming/rotating/scaling etc. etc.

end if
"

ps: this is also old code, I copied parts of it from a forum. Not updated for 64 bit either.. :)



edit: there was a bug in the code :)

probiner
05-16-2010, 08:37 AM
edit: there was a bug in the code :)

http://erikalstad.com/backup/anims.php_files/ohmy.gif cheap shot boomerang.

Kuzey
05-16-2010, 08:42 AM
Yes, and... no. As I mentioned a lot earlier talking about FPrime. I've seen cases where FPrime started a render after loading a scene way before any of the OpenGL views were ready, and I've also seen the same when scrubbing through animations.

Actually, the difference between an OpenGL viewport and a progressive renderer.

Cheers,
Mike

I just picked OpenGL off the top of my head...but I presumed OpenGL viewports would be faster in Core than 9.6. Newer/better code and all that....a bit like comparing a 1930's car to today's model..if you know what I mean.

Here's a question for ya Mike...is it at all possible to have a mix of OpenGL or even wireframe and progressive renderer in the same viewport?

Say, have the object being manipulated rendered in OpenGL, while the other non moving objects, continue rendering with the progressive renderer. Once the editing is complete, have vpr just render that object. Or it restarts the full render....if the changes, affect other objects within the scene...like casting shadows or reflections changing on non stationary objects etc.

Kuzey

Kuzey
05-16-2010, 08:53 AM
What's up with the Hardcore program...if you join, sooner or later you become feral over time??

Seems like *Pete* and a few others, are still neutral and haven't been affected by this change in behavior :goodluck:

:D

Kuzey

Cageman
05-16-2010, 09:00 AM
I just picked OpenGL off the top of my head...but I presumed OpenGL viewports would be faster in Core than 9.6. Newer/better code and all that....a bit like comparing a 1930's car to today's model..if you know what I mean.

Here's a question for ya Mike...is it at all possible to have a mix of OpenGL or even wireframe and progressive renderer in the same viewport?

Say, have the object being manipulated rendered in OpenGL, while the other non moving objects, continue rendering with the progressive renderer. Once the editing is complete, have vpr just render that object. Or it restarts the full render....if the changes, affect other objects within the scene...like casting shadows or reflections changing on non stationary objects etc.

Kuzey

I think these sort of things are uneccesary, since it is a flip of a button to jump between VPR and OGL. Trying to add all these crazy things are just weird, and in the end it might confuse people even more than having clear labels: VPR, OGL; make your choice.

Hieron
05-16-2010, 09:04 AM
What's up with the Hardcore program...if you join, sooner or later you become feral over time??


Ow come on, I was being very friendly up there a few posts up, all in good fun. Had to look up feral btw :)


Do note: I agree with your idea of OpenGL overlay as stated about 3x now (as an option in the view render settings, to complement a bug free VPR :P), whether that is doable/fast, no idea. Someone who can actually write code (above is about as good as it gets for me) might answer that.

Cageman
05-16-2010, 09:04 AM
Kuzey,

Maybe you should join HardCORE, since you seem to have alot of ideas, and chances are much higher that you are going to be heard in HC. Also, since you are debating something you actually havn't used yet, I think it would be good for you to feel what it is like when working with VPR.

OnlineRender
05-16-2010, 09:08 AM
Kuzey,

Maybe you should join HardCORE, since you seem to have alot of ideas, and chances are much higher that you are going to be heard in HC. Also, since you are debating something you actually havn't used yet, I think it would be good for you to feel what it is like when working with VPR.

what we talking about now ? I lost interest at page3 ? ? ? :D

80% complete @ AlanWake *awesome

oliversimonnet
05-16-2010, 09:12 AM
mmm ye
what are we talking about?? is there a debate going on :D
OnlineRender: what's 80% complete? :)

OnlineRender
05-16-2010, 09:15 AM
AlanWake on XBox ! nearly completed it , sat up till 4am last night , awesome !

EDIT :

Did you see SONIC 4 got leaked 2 months eairler than release date ! , sadly you need a jtaged xbox *not softmoded* running homebrew ......

oliversimonnet
05-16-2010, 09:20 AM
aaaa ok lol cool
mm no iv not seen Sonic 4 :S

Lightwolf
05-16-2010, 09:54 AM
I just picked OpenGL off the top of my head...but I presumed OpenGL viewports would be faster in Core than 9.6. Newer/better code and all that....a bit like comparing a 1930's car to today's model..if you know what I mean.
That just shifts the issue, OpenGL is still not interruptible, software rendering is.

Here's a question for ya Mike...is it at all possible to have a mix of OpenGL or even wireframe and progressive renderer in the same viewport?
Sure... but that would allow the OpenGL to slow down the viewport in case of heavy meshes.
Again, OpenGL has to completely draw a frame before you can send it another frame, progressive rendering doesn't.


Say, have the object being manipulated rendered in OpenGL, while the other non moving objects, continue rendering with the progressive renderer. Once the editing is complete, have vpr just render that object. Or it restarts the full render....if the changes, affect other objects within the scene...like casting shadows or reflections changing on non stationary objects etc.
You could, but it wouldn't necessarily be faster.
Acrually, re-reading, ouch, no, at least not easily. You'd change the visibility setting of an item which in case needs to trigger a new render to show the state change, which means that initially you've won nothing. You end up with pixelated and it may refresh over time while you change that one wire-framed item, but once you release it would need to start rendering all over again.
Not good.

And apparently it's a non-issue to people that have actually worked with systems like that in the past few years.

Cheers,
Mike

OnlineRender
05-16-2010, 09:56 AM
*chuckle* its Bash Kuzey Day ! sorry dude ! better You instead of ME :devil: add smiley face to increase sarcasm .
----------------------------------

Edit : talking about smileys , you go on about not being able to upload YT videos have a look at your signature permission :D * damn I'm GOD

Kuzey
05-16-2010, 02:02 PM
Ow come on, I was being very friendly up there a few posts up, all in good fun. Had to look up feral btw :)


Do note: I agree with your idea of OpenGL overlay as stated about 3x now (as an option in the view render settings, to complement a bug free VPR :P), whether that is doable/fast, no idea. Someone who can actually write code (above is about as good as it gets for me) might answer that.

I was having fun as well...but seriously, there seems to be something going on in there. Maybe, it's the us(HC members) v them(Non HC Members) mentality at play...who knows for sure.

Kuzey

Kuzey
05-16-2010, 02:09 PM
*chuckle* its Bash Kuzey Day ! sorry dude ! better You instead of ME :devil: add smiley face to increase sarcasm .


I can take it...I think..hehe :thumbsup:

Kuzey

Kuzey
05-16-2010, 02:17 PM
You could, but it wouldn't necessarily be faster.
Acrually, re-reading, ouch, no, at least not easily. You'd change the visibility setting of an item which in case needs to trigger a new render to show the state change, which means that initially you've won nothing. You end up with pixelated and it may refresh over time while you change that one wire-framed item, but once you release it would need to start rendering all over again.
Not good.

Cheers,
Mike

Yes...I thought that might have been hard to understand. Someone...Oliver I think, showed a video of another progressive renderer...where the changed areas got re-rendered, but not the full scene from scratch. At least, that's how it looked like to me.

I was thinking, maybe...you could have a mask of the area that's being edited so it doesn't render with the rest of the scene (stays in OpenGL as an example). Then once your done, you use the same mask to just render the changed object...I'm thinking it would save time.

Kuzey

Hieron
05-16-2010, 02:21 PM
Maybe, it's the us(HC members) v them(Non HC Members) mentality at play...


yes, that must be it.




Someone...Oliver I think, showed a video of another progressive renderer...where the changed areas got re-rendered, but not the full scene from scratch. At least, that's how it looked like to me.


That's Shaderlight. Look it up on it's own website and play the explanatory video. The first part and all first lines of the voice over is *exactly* the way Fprime has been doing it as well. Not so revolutionary that part. Then he goes on about how Shaderlight remembers the way the pixel was shaded and allows you to change texture colors and bumps to see the result quickly (see how the camera and objects are kept still, how the render isnot a VPR anyway and updates realtime). Which is in no means a "final render state" btw. Color bleeding and reflections on other surfaces wouldn't change.

Also, the entire point of that entire progressive renderer is: it changes in realtime, no delays ever. (and they say it is a good thing, they must be in HC! :))

Lightwolf
05-16-2010, 04:05 PM
Yes...I thought that might have been hard to understand. Someone...Oliver I think, showed a video of another progressive renderer...where the changed areas got re-rendered, but not the full scene from scratch. At least, that's how it looked like to me.
Yes, I saw that one and it's quite neat.


I was thinking, maybe...you could have a mask of the area that's being edited so it doesn't render with the rest of the scene (stays in OpenGL as an example). Then once your done, you use the same mask to just render the changed object...I'm thinking it would save time.

The problem is.. you'd need to refine the area that has been removed to the level of the rest of the render first before the normal render commences.
You'd also need to make sure that all other parts of the image affected by the change actually re-render as well (think shadows, reflections etc... colour bleeding if GI is active).
Basically: the more complex the scene the less sense it makes. From what I remember from the video it also only reacted to changes of surface properties, which is a different ballpark altogether. Heck, even VIPER can do that ;)

Cheers,
Mike

Kuzey
05-17-2010, 02:33 AM
Yes, I saw that one and it's quite neat.

The problem is.. you'd need to refine the area that has been removed to the level of the rest of the render first before the normal render commences.
You'd also need to make sure that all other parts of the image affected by the change actually re-render as well (think shadows, reflections etc... colour bleeding if GI is active).
Basically: the more complex the scene the less sense it makes. From what I remember from the video it also only reacted to changes of surface properties, which is a different ballpark altogether. Heck, even VIPER can do that ;)

Cheers,
Mike

Ok...the selective progressive render idea sounds hard or not worth it. But the mask idea still can work to render manipulated objects in say OpenGL and then have that trigger a full render from scratch. On second thoughts....I guess it could be done without even the mask...something like the funny code I wrote :D

PS.. I remembered something about OpenGL, the implementation in LW wasn't that hot to start off with....so the delay you spoke of (the slowness of OpenGL rendering complex scenes etc.) could be a result of faulty code.

I reported OpenGL bugs that crashed my MacBook back in the 9.5/9.6 beta cycle...only to have it closed as user error. Then in the 9.6.1/LWHC/Core beta, the team hit the great wall of OpenGL bugs. So I presume it was a) a cross platform problem and b) now fixed...so OpenGL renders should now work better or equal to other 3d apps?

Kuzey

Lightwolf
05-17-2010, 02:44 AM
Ok...the selective progressive render idea sounds hard or not worth it. But the mask idea still can work to render manipulated objects in say OpenGL and then have that trigger a full render from scratch. On second thoughts....I guess it could be done without even the mask...something like the funny code I wrote :D
You'd still need the area where the mesh has been removed (to be replaced by the OpenGL version) refined, otherwise that area will be blotchy as you move the item away.


PS.. I remembered something about OpenGL, the implementation in LW wasn't that hot to start off with....so the delay you spoke of (the slowness of OpenGL rendering complex scenes etc.) could be a result of faulty code.
Nope, it's a general issue and it's pretty much the same for D3D as well. The older code only made it worse in some cases.
It's still the same issue though, once you tell the GPU to start rendering a frame using OpenGL/D3D, it can't be aborted.
There's also a reason as to why there's a lot of research at the moment into realtime raytracing for games.

Cheers,
Mike