Hacker Newsnew | past | comments | ask | show | jobs | submit | fuyu's commentslogin

"The point" was to find a large project to test import performance, and it sounds like they hit that point dead center.


What is the point of importing a dataset of this complexity if you can't also work with the data inside the DCC?

Try the thousands of tools and plugins available for Blender with such data and see what happens. Good luck.

I guess my point is: you need to also "fix" any of those that crash/hang/are too slow to make this worthwhile.

Just to be clear again: awesome they fixed the bugs that lead to crashes with this data. Not sure if that large a dataset was required at all to do that though.

But the speed improvements? Do they matter for your average OBJ? And if no one ever imports data of the complexity of the Moana dataset, because they can't work with it afterwards anyway, any speed improvement that is not felt in the average use case is a nice engineering exercise, foremost.

There is a reason why most commercial DCCs, too, struggle with data sets of this size and no one has ever "fixed" this. ;)


> What is the point of importing a dataset of this complexity if you can't also work with the data inside the DCC?

My understanding is, that you need to reproduce the rendering bug which crashes blender to be able to fix it. And being able to reproduce it, needs to be fast. Even if you have a smaller scene which would trigger this bug, without the optimisations it would take a lot of important time in the feedback loop. Now you have a workflow which crashes the rendering in less than 2 minutes.


See this reply from someone else: https://news.ycombinator.com/item?id=32190577


I really don't understand your point at all. You might be right, the use case doesn't exist yet, maybe never. But this never was the point of the blog post.

Making the application wait extremely long or even crash by importing _something_ is a bug in my understanding. Why shouldn't it be fixed? Why shouldn't developers improve performance and blog about it, so other devs learn from it?

It's not about the Moana scene, that's just the test case, so OP has a valid benchmark with human comprehensible durations. The scene could be anything that is smaller and it will be imported faster now.


See the reply to that:

https://news.ycombinator.com/item?id=32191173

>At some point, the little pieces need to be assembled, reviewed and finally rendered. Why wouldn't you do that with the DCC application rather than with specialized, limited tools?


See the explanations in my other replies on this topic.

It is impossible to hold a typical VFX scene in RAM to start with.

Even freelancers doing sim/FX work now have at least 128GB RAM and this is often just enough for proxy work that still gets expanded at render time.

I.e. consider the possibility that your worst estimate of how complex this data could be is off by 1-3 orders of magnitude.

And for your example: the person who signs this off is the VFX supervisor. They don't sign off anything but final frames.


It’s a stress test. It doesn’t have to be reasonable. This is what you do for performance improvement, you push as hard as you can to find the worst actors and fix them.

Performance improvements like this expand the horizons of what is reasonable to do.

There’s a circular logic problem where you argue that performance problems shouldn’t be fixed because nobody actually does this, but nobody does it because of performance problems. No, this effort didn’t solve every performance problem required to do a thing, but did it solve some of it.

“We didn’t do everything so we should have done nothing” is not how you build a performant product.


He sped up parts of the blender pipeline, someone will no doubt benefit.

He does address that the crashing also needs to be fixed but that he doesn't want to be the guy doing that.


100 years is a long time for humanity to look into ways to counteract time travelling trolleys! Sure it _says_ the future trolley will kill 5 people, but if I were in that situation I'm fairly sure I wouldn't be so certain. In your "political" example: Do you want a guaranteed bad outcome now, or what we expect to be the same bad outcome later?


Maybe we have medical resurrection in 100 years, so killing people might not be so bad. Plus future humans get a perfectly preserved example of a 100 year old trolley out of the deal, which is presumably a valuable antique.


> But could you make a better game if you didn't need to funnel people into buying gems at all? The answer is always yes - you always need to give up something to make people buy gems.

This ignores the fact there aren't unlimited resources to develop and maintain a game. Not requiring people to buy gems would improve some areas of the game for sure, but making less money is certain to impact other areas of the game - you always need to give up something in order to fit things in budget.


Aren't the biggest costs from bandwidth, not storage? I'm sure they would love to reduce data transmission by 20% for browsers that support it.


CDNs would love to bill customers 20% less for bandwidth used? Customers will be able to move to storing JPEG XL files on CDNs and reduce their own storage and bandwidth costs, but I was responding to the claim that it would be in CDN's interest to hurry the transition, and I think it will be a loss for CDNs.


I'm not sure what tone your comment is intended to give off, but does there exist a person who _isn't_ willing to trade privacy for convenience to some degree? One certainly couldn't be using the internet or participating in society if they weren't willing to give up some privacy.


Autism refers to Autism Spectrum Disorder. There is nothing wrong with using "on the spectrum" for people with ASD. There are also several usages of "Autism" by itself, so I don't know where you got the idea that it is being treated as a bad word.


There's a bit of nomenclatural history here. There was autism, which usually manifested as a severe disorder that significantly impaired functioning. People with a social deficit like autism, but who were otherwise fine, were usually diagnosed with Asperger's syndrome, which was considered like autism but not quite autism. Then there was high-functioning autism, which wasn't the same as Asperger's syndrome, a major distinguishing characteristic being that people with HFA had a speech deficit in early childhood while people with AS did not.

That was where things stood as of the DSM IV. Then the DSM V came along and lumped all of the above into a single classification of "autism spectrum disorder".


Because people aren't saying the word autism outright and are using euphemisms, like bad words are.


If I were to ask you if I could get a refund for an item out of warranty, what language would you use to refuse me? I'm struggling to come up with a response that doesn't use the terms "unable" or "can't" that wouldn't come across as fairly rude.


"We do not issue refunds for items with expired warranties"

Notice that the policy is clearly stated in the rejection and there is no ambiguity.


You would be lying - and people will call you out on this, because they will find out that you have in fact issued refunds for products with expired warranties.


This level of semantics is pointless.

They could write "We generally do not issue refunds for items outside of warranty" and they're back to the statement being just one level more vague, and thus more true.

But in reality, both of those mean the same thing. Writing "We don't issue refunds outside of warranty periods" has an understood "excluding exceptional circumstances". Everyone knows it's there. Only people who are pedantic to the point of uselessness will argue about this, and you'll find out that the courts generally have little sympathy for that.

All human languages so far are inexact. Math is probably the most exact language we've invented for communicating ideas, but languages that the general public knows are all inexact.

If the correct thing is communicated unambiguously, that's already a success, even if a pedantic person can say "I know you mean that you don't 'generally' do it, so the absolute there is a lie", the fact that the pedant can point it out means they absolutely understood what was being conveyed correctly.


This level of semantics is indeed pointless - to clarify, your comment supports both what you wrote and Google's use of the "unable" wording in their response; they are unable to reinstate your account <without introducing liability to lawsuits regarding unfair business practices> <and except in exceptional circumstances>.


The person responding at a big corporation is often unable to, for practical purposes as a result of policies other than in exceptional circumstances.

When you write in and ask them, please steal a million dollars and give it to me, while they might be able to figure out a way to steal and give it to you, for policy and job performance reasons they are unable to. They say - "I'm unable to do that for you". Who cares if they somehow could - we all understand they have chosen not to.

We are unable to reinstate your account = person responding does not have policy authority to reinstate your account and the exceptional circumstance was not identified.


That feeling is specifically because we all know that depersonalizing and speaking passively 'softens' the blow.

"As your product is out of warranty we will not be issuing a refund."

Sounds rude, right? Because it draws attention to the fact that the decision is, at some level, completely arbitrary. But if you have your left hand write the policy and your right hand enforce it then you can say.

"I'm sorry but I'm unable to issue a refund because your product is out of warranty."

Makes it sound like that's just how the world works, doesn't it? And you come away feeling like "aww man they can't" instead of "they won't, money grubbing assholes." Customer service is, at its core, about managing emotions and often delivering bad news in a way that preserves the company's image.


> Unfortunately the warranty on your product has expired and we do not issue refunds for products outside the warranty period.

If you pressed me I would admit that yes, in some exceptional cases we issue refunds for products outside of warranty but we're not doing so in this case because [whatever, the product broken due to misuse, etc.].

To say I am not issuing a refund or that I do not issue refunds on out-of-warranty is truthful or reasonably so. It's perfectly possible to communicate that without being rude or claiming to be "unable."


How about "I'm afraid I can't do that, Dave"?


computer says no


A better and more honest answer than so much of the apologetics spouted in this thread.

I'm amazed at the people defending this type of verbiage... like at all.


You are not eligible for a refund under our warranty. Let us know if you have any more questions.


Genshin Impact is a recent game that has included a kernel mode anti-cheat. I would be very surprised if the majority of players know that it exists, or understand what it means to have it run in kernel mode.

The Genshin website previously allowed anyone to view the phone number you have linked to your account via the password reset mechanism. Due to common reports of accounts getting stolen (and unable to be recovered), two factor auth has been highly requested, but doesn't seem to be a priority. I'm skeptical that they strongly care about the security of their users.

Even if Genshins anti-cheat is completely secure, as kernel anti-cheat becomes more common it's inevitable that we will get an instance that is full of security holes. Unfortunately as long as the user can't play their favorite game without it, they will happily install it.


Even if the security is bad does it even matter? User mode is enough for malware. "Sure an attacker could mine crypto, DoS people, use me as a proxy, keylog me, use my webcam, steal my saved usernames and passwords, but at least they can't upgrade my graphics drivers", said no one ever.


Oh, there's a lot more "fun" stuff you can do in kernel mode. One comedic example is setting the CPU Vcore offset to +2.2V for fun/revenge. I don't know if it will destroy CPUs permanently, but it would be an interesting experiment.

More importantly though, once you're in the kernel, its much easier to hide your presence to all manner of Windows sysadmin tools.


Genshin Impact's anti-cheat is not completely secure: you can use it to read/write umode memory / read kmode memory with kernel privileges: https://github.com/ScHaTTeNLiLiE/libmhyprot

Mirror repo after the original author took the repo down, but still exploitable AFAIK.


Explanation of the exploit here:

https://github.com/Luohuayu/evil-mhyprot-cli

Not as bad as capcom.sys:

https://mobile.twitter.com/TheWack0lian/status/7793978407622...

The effect is the same though: ring 0 code execution.


I’m an anti cheat dev and I think client-side anti cheats make no sense on a typical MMO. Pretty much all cheats for those types of games can be detected server-side. RuneScape is a great example of this.


Wanting to spend more time doing things such and volunteering or gardening are exactly reasons why someone might pursue early retirement. It sounds like you agree with the concept but are getting distracted by terminology.


Yea or maybe the terminology itself is bad and the “RE” aspect of FIRE might need to go away. If you’re volunteering for example are you not working? What is work? Definitions definitions...

But that’s my fault. I wasn’t specific enough. :) thanks!


I very much prefer using Vim, but the debugging experience is much better in VSCode. The language server experience in VSCode is also better (though vim is getting there!), and there are many other small trade-offs that one may prefer.

Emacs I haven't tried nearly as much, but it has a poor Windows OS experience, and is also historically a "bloated" software ("Eight Megabytes and Constantly Swapping").

Of course there is no reason Vim couldn't be modified to do everything VSCode does but better, but until that happens VSCode will still have a place in my toolbox.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: