Re: ocean LOD bug fix -> desired result achieved! r: 38157

On Tue, Jun 12, 2012 at 2:36 AM, res <[email protected]> wrote:

> On 10.06.2012 22:23, Naman Gupta wrote:
> > Namaste,
> >
> >    I managed to get desired result for Ocean LOD using multiple
> > buffers.  code is very messy but yeah understandable. also optimization
> > is remaining.   any comments?
> >
> > i'll work on fixing shaders now. and will fix the code and optimize
> > in July as per schedule.  or could be made flexible
>
> It looks much nicer without those gaps! :)
>
> About the code: well, you think yourself it's a bit messy... so I
> recommend you clean it up a bit before proceeding. A good start would be
> to bring it into a shape that you would consider “clean” by your own
> standards ;)
> There's obviously a lot of repetition where the boundary meshes are
> concerned. I'd probably try to factor the similar but not quite the same
> code blocks into a function and/or loop. (Something simple as merging
> the separate …_TL, …_TH members into one array would really make turning
> the repeated blocks of code into loops the natural thing to do.)
>
on it.

>
> The generation of the boundary meshes is a bit ...opaque... itself. (But
> then, mostly but not quite entirely code with a lot of arithmetic on
> indices tends to be so.) Some additional commentary in the code would
> really help here. If I gathered it right you used some paper/online
> resource as the basis for the boundary mesh logic; it would be really
> good to cite this. If the algorithm can be well explained in a graphical
> way and you feel fancy, perhaps add some ASCII art.
>
ASCII art. would love to do that ;).

>
> About optimization: I compared waterdemo2 on trunk and your branch; with
> my not-so-blazingly-fast integrated graphics the numbers are ~60fps
> (trunk) vs ~30fps (branch) – clearly, there' still potential for
> optimization here.

strange trunk ocean demo was like ~250 fps on my machine. and ~70 fps with
new one.

> One good reason for approaching this now, instead of later (July), is
> that the whole boundary thing is still fresh in your head, which can
> help when trying to look at it from different angles.
> Personally, I'd like to now how my “brute” approach of having indices
> for a whole LOD level for each possible combination of half-res vs
> full-res for an edge stacks up against current approach.
> Did you have any ideas for optimization while writing the code? If so,
> perhaps just “experiment” a bit and see how things perform. If you feel
> the time is slipping too much you can still put optimization on the
> “todo” list and move on.
>
Yes, i had ideas about Optimization. The attached boundaries to ocean cells
are actually a complete ocean cell itself(with tris changed). reducing
vertex, tex etc count from each ocean cell's boundary would significantly
increase the performance. but again indexes(tris) has to be rewritten and
then all the boundaries has to positioned as presently their position is
governed by indexes of a complete cell.

-Naman

>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Crystal-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/crystal-develop
>
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Crystal-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-develop